Check Request Headers using XACML in Fiware platform - fiware

I'm trying to integrate AuthzForce with Keyrock for advanced PDP and wanted to know how custom headers check rule can be made in XACML policies. As per my understanding and documentation, they've specified that with AuthzForce its possible to check the body, match time of request and more. But nowhere i could find a resource on how a policy/rule can be made to check custom headers.
Any suggestion or link for any documentation is appreciated.

#cdan is correct - the Authzforce PDP, like any PDP can only adjudicate on matters if it is passed the appropriate information. The PEP Proxy you use will need to obtain and forward the information needed to adjudicate. For example, in the Wilma PEP Proxy, the payload for Authzforce is defined here
In the Wilma PEP Proxy the the XACML Policy is defined in JavaScript as shown below and then translated into XML before being sent to Authzforce:
const XACMLPolicy = {
Request: {
xmlns: 'urn:oasis:names:tc:xacml:3.0:core:schema:wd-17',
CombinedDecision: 'false',
ReturnPolicyIdList: 'false',
Attributes: [
{
Category: 'urn:oasis:names:tc:xacml:1.0:subject-category:access-subject',
Attribute: [
{
"AttributeId":"urn:oasis:names:tc:xacml:1.0:subject:subject-id",
"IncludeInResult": "false",
"AttributeValue":{
"DataType":"http://www.w3.org/2001/XMLSchema#string",
"$t":"joe"
}
}
]
},
{
Category: 'urn:oasis:names:tc:xacml:3.0:attribute-category:resource',
Attribute: [
{
AttributeId: 'urn:oasis:names:tc:xacml:1.0:resource:resource-id',
IncludeInResult: 'false',
AttributeValue: {
DataType: 'http://www.w3.org/2001/XMLSchema#string',
$t: appId
}
},
{
AttributeId: 'urn:thales:xacml:2.0:resource:sub-resource-id',
IncludeInResult: 'false',
AttributeValue: {
DataType: 'http://www.w3.org/2001/XMLSchema#string',
$t: escapeXML(resource)
}
}
]
},
{
Category: 'urn:oasis:names:tc:xacml:3.0:attribute-category:action',
Attribute: {
AttributeId: 'urn:oasis:names:tc:xacml:1.0:action:action-id',
IncludeInResult: 'false',
AttributeValue: {
DataType: 'http://www.w3.org/2001/XMLSchema#string',
$t: action
}
}
},
{
Category: 'urn:oasis:names:tc:xacml:3.0:attribute-category:environment'
}
]
}
};
Each Attribute in this payload is something that may need to be checked.
To add a check for a custom header, you'll need to extract it from the incoming payload and add another attribute (of category urn:oasis:names:tc:xacml:3.0:attribute-category:resource) with an appropriate AttributeId.
Of course the XACML rules you define will also need to refer to this same new Attribute Id when setting the access policy e.g. "if custom header present then PERMIT else DENY".

Related

How can we restrict the user to a specific date format in the AWS tag policy?

I am creating a Tag Policy in AWS. I need to develop a rule to restrict the value of one of the keys to a specific format.
I need the end user to enter the value in yyyymmdd format. How can I build the JSON policy to reflect this?
This is what I have so far. I am using it in
{
"tags": {
"DateCreated": {
"tag_key": {
"##assign": "DateCreated"
},
"tag_value": {
"##assign": [
"yyyymmdd"
]
}
},
"enforced_for": {
"##assign": [
"s3:bucket" ]
}
}
}
}
I think tag policies do not support regex etc. to validate values so alternative solution would be using AWS Config and writing a custom config policy rule by using Guard policy language or Lambda function.
Use proactive evaluation to restrict users to create tags which does adhere to set rules.
https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules.html

JSON HAL - specify different formats for links

I know that you can indicate a "type" with a HAL link, like so:
{
_links: {
self: {
href: "http://example.site/api/orders/1",
hreflang: "en_US",
type: "application/hal+json"
}
}
}
But I'd like to explain the different types that are available at that href. For example, I want to state that both "application/hal+json" and "application/pdf" are valid representations Accept-ed by the resource URI.
Maybe something like:
{
_links: {
self: {
href: "http://example.site/api/orders/1",
hreflang: "en_US",
type: [
"application/hal+json",
"application/pdf"
]
}
}
}
or... ?
Is this possible? If so, how?
HAL uses the Link spec: https://datatracker.ietf.org/doc/html/rfc5988
This spec list only a single type per Link:
The "type" parameter, when present, is a hint indicating what the
media type of the result of dereferencing the link should be. Note
that this is only a hint; for example, it does not override the
Content-Type header of a HTTP response obtained by actually following
the link. There MUST NOT be more than one type parameter in a link-
value.

CORS in POST request chrome extension development [duplicate]

I can't see an answer to this in the Developer's Guide, though maybe I'm not looking in the right place.
I want to intercept HTTP requests with a Chrome Extension, and then forward it on, potentially with new/different HTTP headers - how can I do that?
PS: I am the author of Requestly - Chrome/Firefox extension to modify HTTP requests & responses.
It was certainly not possible when OP asked the question but now you can use WebRequest API with Manifest V2 and DeclarativeNetRequest API with Manifest V3 to write your own extension to modify Request & Response Headers.
Manifest V2 code
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
for (var i = 0; i < details.requestHeaders.length; ++i) {
if (details.requestHeaders[i].name === 'User-Agent') {
details.requestHeaders.splice(i, 1);
break;
}
}
return { requestHeaders: details.requestHeaders };
},
{urls: ['<all_urls>']},
['blocking', 'requestHeaders' /* , 'extraHeaders' */]
// uncomment 'extraHeaders' above in case of special headers since Chrome 72
// see https://developer.chrome.com/extensions/webRequest#life_cycle_footnote
);
Google Chrome is deprecating webRequest Blocking APIs in the Manifest V3. As per the official statement from Google on 28th Sep 2022, all extensions with Manifest v2 won't run on Chrome from June 2023 onwards. Here's an approach to Modify Request & Response headers with Manifest v3 - https://github.com/requestly/modify-headers-manifest-v3
Manifest V3 Code:
rules.ts
const allResourceTypes =
Object.values(chrome.declarativeNetRequest.ResourceType);
export default [
{
id: 1,
priority: 1,
action: {
type: chrome.declarativeNetRequest.RuleActionType.MODIFY_HEADERS,
requestHeaders: [
{
operation: chrome.declarativeNetRequest.HeaderOperation.SET,
header: 'x-test-request-header',
value: 'test-value',
},
]
},
condition: {
urlFilter: '/returnHeaders',
resourceTypes: allResourceTypes,
}
},
{
id: 2,
priority: 1,
action: {
type: chrome.declarativeNetRequest.RuleActionType.MODIFY_HEADERS,
responseHeaders: [
{
operation: chrome.declarativeNetRequest.HeaderOperation.SET,
header: 'x-test-response-header',
value: 'test-value',
},
]
},
condition: {
urlFilter: 'https://testheaders.com/exampleAPI',
resourceTypes: allResourceTypes,
}
},
];
background.ts
import rules from './rules';
chrome.declarativeNetRequest.updateDynamicRules({
removeRuleIds: rules.map((rule) => rule.id), // remove existing rules
addRules: rules
});
The complete source code is available in the GitHub repo - https://github.com/requestly/modify-headers-manifest-v3
If you want to use an existing Chrome/Firefox/Edge Extension, you can use Requestly which allows you to modify request and response headers. Have a look at this snapshot:
Modifying request headers ( https://developer.chrome.com/extensions/webRequest ) is supported in chrome 17.
You are looking at the right place, but intercepting HTTP requests does not exist yet, but the extension team is aware that it's a popular request and would like to get to it sometime in the near future.
Keep in mind that starting from chrome 72, some headers are not allowed unless you add extraHeaders in opt_extraInfoSpec
So the above example in #sachinjain024's answer will look something like this:
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
for (var i = 0; i < details.requestHeaders.length; ++i) {
if (details.requestHeaders[i].name === 'User-Agent') {
details.requestHeaders.splice(i, 1);
break;
}
}
return { requestHeaders: details.requestHeaders };
},
{urls: ['<all_urls>']},
[ 'blocking', 'requestHeaders', 'extraHeaders']
);
For more info, check the documentation Screenshot from the documentation https://developer.chrome.com/extensions/webRequest#life_cycle_footnote
For extensions using manifest version 3, you can no longer use chrome.webRequest.onBeforeSendHeaders.*. The alternative is chrome.declarativeNetRequest
Make the following changes in your manifest.json:
{
...
"manifest_version": 3,
"background": {
"service_worker": "background.js"
},
"host_permissions": ["<all_urls>"],
"permissions": [
"declarativeNetRequest"
],
...
}
💡 "<all_urls>" is for modifying all outgoing urls's headers. Restrict this for your scope of your work
Make the following changes in your background.js:
// ...
const MY_CUSTOM_RULE_ID = 1
chrome.declarativeNetRequest.updateDynamicRules({
removeRuleIds: [MY_CUSTOM_RULE_ID],
addRules: [
{
id: MY_CUSTOM_RULE_ID,
priority: 1,
action: {
type: "modifyHeaders",
requestHeaders: [
{
operation: "set",
header: "my-custom-header",
value: "my custom header value"
}
]
},
condition: {
"resourceTypes": ["main_frame", "sub_frame"]
},
}
],
});
Result
Read the docs https://developer.chrome.com/docs/extensions/reference/declarativeNetRequest/
You could install ModHeader extension and add headers:
You can use WebRequest API which is now deprecated it allows you to modify request/response headers.
You can upgrade your extension to Manifest V3 to be able to use DeclativeNetRequest which also supports modifying request/response headers.
Or you can install Inssman chrome extension.
It allows you to modify HTTP(S) request/response headers, reqirect and block request, return custom data like HTML/CSS/JS/JSON and more.
And it is open source project

AMP Analytics "destinationDomains" not working in Linker config

I am trying to enable a linker string for links to my domains from my AMP site.
The current config is working only for links to the "canonical" domain at present, which is the default behavior.
I am also trying to enable it for links that are sent to my app's domain.
I've tried many variations of the code below (including using non-valid JSON array strings, as set out in the documentation here: https://ampbyexample.com/advanced/joining_analytics_sessions/#destination-domains) however this does not seem to work.
I am hoping this is a syntax or config issue but I am starting to have doubts. This is my code:
<amp-analytics type="gtag" data-credentials="include">
<script type="application/json">
{
"vars": {
"gtag_id": "AW-XXXXXX",
"config": {
"UA-XXXXX-X": {
"groups": "default"
},
"AW-XXXXXX": {
"groups": "default"
}
}
},
"linkers": {
"enabled": true,
"proxyOnly": false,
"destinationDomains": [ "amp.mydomain.com", "www.mydomain.com", "app.altdomain.ly" ]
},
"triggers": {
"trackPageview": {
"on": "visible",
"request": "pageview"
}
}
}
</script>
</amp-analytics>
I've also tried setting it out with a nested <paramName> object as follows, but I get the same result (works on canonical only):
...
"linkers": {
"Linker1": {
"ids": {
"_cid": "CLIENT_ID"
},
"proxyOnly": false,
"destinationDomains": [ "amp.mydomain.com", "www.mydomain.com", "app.altdomain.ly" ],
"enabled": true
}
}
...
Since you are using gtag, I think you might need to use the GTAG's configuration to configure the domains. Instructions are available here.
Basically, the config looks like this:
<amp-analytics type="gtag" data-credentials="include">
<script type="application/json">
{
"vars" : {
"gtag_id": "<GA_TRACKING_ID>",
"config" : {
"<GA_TRACKING_ID>": {
"groups": "default",
"linker": { "domains": ["example.com", "example2.com"] }
}
}
}
}
</script>
</amp-analytics>
You can check first the proper format of linkers in AMP:
"linkers": {
<paramName>: {
ids: <Object>,
proxyOnly: <boolean>,
destinationDomains: <Array<string>>,
enabled: <boolean>
}
}
paramName - This user defined name determines the name of the query
parameter appended to the links.
ids - An object containing key-value pairs that is partially encoded
and passed along in the param.
proxyOnly - (optional) Flag indicating whether the links should only
be appended on pages served on a proxy origin. Defaults to true.
destinationDomains - (optional) Links will be decorated if their
domains are included in this array. Defaults to canonical and source
domains.
enabled - Publishers must explicity set this to true to opt-in to
using this feature.
This linker uses this configuration to generate a string in this structure: <paramName>=<version>*<checkSum>*<idName1>*<idValue1>*<idName2>*<idValue2>... For more details see Linker Param Format.

Sencha Rest Proxy not able to access Data available on Localhost:3000 (Redmine)

This is my model
Ext.define('ThemeApp.model.peopleModel', {
extend: 'Ext.data.Model',
fields: [
{ name: 'id' },
{ name: 'subject' },
{ name: 'description'}
],
proxy: {
type: 'rest',
format: 'json',
limitParam:"",
filterParam: "",
startParam:'',
pageParam:'',
url:'http://localhost:3000/issues/1',
/*
api: {
read : 'http://localhost:3000/issues'
},*/
headers: {'Content-Type': "application/json" },
//url : 'http://api.soundcloud.com/tracks?q=allah%20dita%20rehman%20khan&client_id=0b19b8dc2526b43eae19f03b2eab6798&format=json&_status_code_map[302]=200',
reader: {
type: 'json',
rootProperty:'issues'
},
writer: {
type: 'json'
}
}});
This is my store:
Ext.define('ThemeApp.store.peopleStore', {
extend: 'Ext.data.Store',
model: 'ThemeApp.model.peopleModel',
storeId: 'peopleStore',
pageSize: 500,
autoLoad: true });
All I am trying to do is to fill this grid using Rest proxy, and to test GET and POST methods of rest proxy. I was able to ready soundcloud api using this application but when I tried to read Redmine issues (localhost:3000/issues.xml)
I am getting this error:
http://localhost:3000/issues.json just Look like http://www.redmine.org/issues.json only with lesser data. Also Localhost:300/issue.json do exsist !
Any Idea ?
You are trying to perform CORS requests against the Redmine API. Unfortunately, Redmine currently doesn't support CORS, so this is not possible without further infrastructure changes (which might compromise security if done incorrectly).
There are plugins adding CORS headers to Redmine reponses, but from what I have seen yet, they do not fully ensure a secure system yet.
Given these restrictions, your requests to Redmine will only be valid if your ExtJS app is served from the same host and port as Redmine so that it runs in the same origin and thus works without any explicit CORS support. You could enable this by using a proxy server (e.g. nginx) before both Redmine and the static files of your ExtJS app so ensure the same origin.
http://localhost:3000/issues.json
exists, but
http://localhost:3000/issues/1.json
does not exist.
In order to get a rest api to work, you need to use url rewriting.
If you have a flat .json file, you should not use a rest proxy but a json proxy, and you will not have this problem.