I'm running XACML using the Authzforce PDP engine and a configuration pdp.xml file, that looks like:
<?xml version="1.0" encoding="UTF-8"?>
<pdp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://authzforce.github.io/core/xmlns/pdp/6.0"
version="6.0.0">
<rootPolicyProvider id="rootPolicyProvider"
xsi:type="StaticRootPolicyProvider" policyLocation="${PARENT_DIR}/policy.xml" />
</pdp>
Now, the file ${PARENT_DIR}/policy.xml, that is read by the PDP engine through the rootPolicyProvider contains the actual XACML policies and is becoming fairly large. So, I would like to divide the XACML policies in multiple files policy1.xml, policy2.xml, policy3.xml, etc. These files then need to be read by the PDP engine.
Does anyone know whether the PDP engine configuration xml-file is able to specify this using multiple policyProviders or otherwise? It shouldn't be too difficult, but I have not found any solution yet after a few hours of search on the web.
Looking forward to your replies.
Thx, Jack.
For this use case, I recommend to upgrade to AuthzForce Core 14.0.0 or later. Then you have two options (beware the XML schema and namespace have changed a bit):
Multiple 'policyLocation' elements, for example:
<?xml version="1.0" encoding="UTF-8"?>
<pdp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://authzforce.github.io/core/xmlns/pdp/7.0" version="7.0.0">
<policyProvider id="refPolicyprovider" xsi:type="StaticPolicyProvider">
<policyLocation>${PARENT_DIR}/policy1.xml</policyLocation>
<policyLocation>${PARENT_DIR}/policy2.xml</policyLocation>
</policyProvider>
<rootPolicyRef>policy1</rootPolicyRef>
</pdp>
Use a wildcard pattern as 'policyLocation', for example (including all policy files with '.xml' extension):
<?xml version="1.0" encoding="UTF-8"?>
<pdp xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://authzforce.github.io/core/xmlns/pdp/7.0" version="7.0.0">
<policyProvider id="refPolicyprovider" xsi:type="StaticPolicyProvider">
<policyLocation>${PARENT_DIR}/*.xml</policyLocation>
</policyProvider>
<rootPolicyRef>policy1</rootPolicyRef>
</pdp>
In both cases, the 'rootPolicyRef' identifies the root policy (where the PDP evaluation starts). In this case, the root policy is supposed to combine the other policies, i.e. be a XACML PolicySet with a defined PolicyCombiningAlgId and one or more PolicyIdReferences or PolicySetIdReferences to the other policies.
You can find a full example using the wildcard option on authzforce github.
Also you can find more info about the PDP configuration format (latest version) in the XML schema.
Related
I need to set the following feature in group policy editor on really many computers of the same model.
Computer configuration -> Administrative Templates -> Windows Components -> Locations and Sensors -> Deactivate Sensors
And before I do this, I would like to check if it has not already been set.
Is there any way to do this via VB6 / API?
I have googled, and I didn't find any solution, only super complicated ones. Do I have to use AutoHotKey to do this? :-D
Thank you!
Edit:
I found a file here: C:\Windows\System32\GroupPolicyUsers\Machine\comment.cmtx
<?xml version='1.0' encoding='utf-8'?>
<policyComments xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0" schemaVersion="1.0" xmlns="http://www.microsoft.com/GroupPolicy/CommentDefinitions">
<policyNamespaces>
<using prefix="ns0" namespace="Microsoft.Policies.Sensors"></using>
</policyNamespaces>
<comments>
<admTemplate></admTemplate>
</comments>
<resources minRequiredRevision="1.0">
<stringTable></stringTable>
</resources>
</policyComments>
Perhaps I can just check for this file...
Edit 2:
This file doesn't seem to do anything. It merely shows the last change...
The real file seems to be C:\Windows\System32\GroupPolicyUsers\Machine\Registry.pol
Now I am just reading the said Registry.pol and overwriting it when necessary.
Requires admin right though.
I have found a lot of documentation about how to set the order in which the policies are applied to a proxy using API Manager but nothing about how to change it when you are using only the API gateway standalone. Any idea?
There is a more deterministic way of making sure in which order policies are applied than depending on the order of files on the file system.
If you are using online policies (ie policies that are defined on API Manager side), then you have to define the order there. If you rename an online policy, it simply will be removed in the next polling cycle by the runtime.
If you are using offline policies (ie policies that are not defined on API Manager side, and that you have to deploy manually to the policies folder), then you can define the order in which they will be applied by defining the order attribute in the policy tag. For example:
<?xml version="1.0" encoding="UTF-8"?>
<policy
xmlns="http://www.mulesoft.org/schema/mule/policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:mule="http://www.mulesoft.org/schema/mule/core"
xmlns:api-platform-gw="http://www.mulesoft.org/schema/mule/api-platform-gw"
xsi:schemaLocation="http://www.mulesoft.org/schema/mule/policy http://www.mulesoft.org/schema/mule/policy/current/mule-policy.xsd
http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/api-platform-gw http://www.mulesoft.org/schema/mule/api-platform-gw/current/mule-api-platform-gw.xsd"
online="false"
id="12345"
policyName="SimpleLogger"
order="100">
<before>
<mule:logger level="INFO" message="A message" />
</before>
<pointcut>
<api-platform-gw:api-pointcut apiName="your API name" apiVersion="your API version Name"/>
</pointcut>
</policy>
Take into account that even if you define the order, CORS and Throttling/RateLimit policies are always applied first, regardless of the order specified in those or other policies.
If two or more policies have the same order, then the runtime will decide in which order they will be applied after applying all the policies with lower order number defined.
Policies with no order specified are applied after all the policies in which order was specified are applied.
Best regards,
Nahuel.
I was able to change the policy order refactoring the name of the policies files adding a number as a prefix. The number will be used to set the order.
Ex.
000-client-id-enforcement.xml
111-json-thread-protection.xml
222-custom-policy.xml
These policies will be executed in the order
1st - client-id-enforcement
2nd - json-thread-protection
3rd - custom-policy
Even though I'm setting Compavility version in request header (967), when I'm making a call (GeteBayDetails in that case), the response comes with version higher than I need and want (979). These applies to both app I'm currently developing and even API Test Tool. Is there something that I'm missing? Or the Version tag in response isn't related to Compability Level?
Header:
X-EBAY-API-SITEID:212
X-EBAY-API-COMPATIBILITY-LEVEL:967
X-EBAY-API-CALL-NAME:GeteBayDetails
Body:
<?xml version="1.0" encoding="utf-8"?>
<GeteBayDetailsRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<RequesterCredentials>
<eBayAuthToken>...</eBayAuthToken>
</RequesterCredentials>
</GeteBayDetailsRequest>
And the response:
<?xml version="1.0" encoding="UTF-8"?>
<GeteBayDetailsResponse
xmlns="urn:ebay:apis:eBLBaseComponents">
<Timestamp>2016-09-27T11:21:41.341Z</Timestamp>
<Ack>Failure</Ack>
<Errors>
<ShortMessage>Nieznany błąd.</ShortMessage>
<LongMessage>Nieznany błąd.</LongMessage>
<ErrorCode>17460</ErrorCode>
<SeverityCode>Error</SeverityCode>
<ErrorClassification>RequestError</ErrorClassification>
</Errors>
<Version>979</Version>
<Build>E979_INTL_API_18061441_R1</Build>
</GeteBayDetailsResponse>
PS. As far as I know, request fails because of the newer version of the API. And worked before like a charm. Thats why I want to stick to 967.
What you are seeing is normal behavior in that the response will always contain the most recent API schema that could service your request. I encounter many calls for which there are no applicable execution differences between the requested schema and the performing schema, for a given particular request. Also this returning "latest schema version that could service the API request" behavior is how you can determine if you can move up your compatibility level safely, as support drops off periodically.
Of course when the response has a lower schema than the latest in the release notes for the API, then you know you are in a situation where at some point you have to change your code to reflect what has been deprecated or changed before the support for the last schema that can service your particular request ends.
This eBay DTS article mentions this Information in the API Response
as well as going over the eBay API schema versioning process.
Also, be sure on XML POST requests to specify the API schema version in the request itself using the Version tag, not just the HTTP header as with the example call code for the GeteBayDetails API documentation:
<?xml version="1.0" encoding="utf-8"?>
<GeteBayDetailsRequest xmlns="urn:ebay:apis:eBLBaseComponents">
<!-- Call-specific Input Fields -->
<DetailName> DetailNameCodeType </DetailName>
<!-- ... more DetailName values allowed here ... -->
<!-- Standard Input Fields -->
<ErrorLanguage> string </ErrorLanguage>
<MessageID> string </MessageID>
<Version> string </Version>
<WarningLevel> WarningLevelCodeType </WarningLevel>
</GeteBayDetailsRequest>
Hope this helps
Description
I have created multiple XACML files containing several policies which are evaluated according the first-applicable rule-combining-algorithm.
Sometimes I am unable to avoid code duplication in XACML and I have to copy a certain XACML policy at several locations in the XACML file.
Is it possible to avoid code duplication in XACML via e.g. <import file="xacml/deny-policy.xacml"/> like in xml or via another way?
Actually there is already way to refer already existing policies inside another policy for reusability.
You may use either of the two ways:
Using Policy Id reference : Call existing policy inside another policy/PolicySet.
Using Policy Set id reference : Call exisitng PolicySet inside another policySet
For example below is the way to call an existing policy inside another policy:
Existing policy "policy1" to be resued:
<Policy PolicyId="policy1" ....>
....
....
</Policy>
Call "policy1" inside another policy:
<Policy PolicyId="MasterPolicy" ....>
<Description>Master Policy Set</Description>
<Target>
....
</Target>
<PolicyIdReference>policy1</PolicyIdReference>
</Policy>
In addition to what Yusuf said, you can also use variable definitions. Variable definitions are expressions you can define inside policies and which you can reuse inside rule conditions.
See the XACML specification for more details.
I am creating a REST web service that returns XML documents by serializing .NET objects using the DataContractSerializer. It works very nicely returning documents like:
<?xml version="1.0" encoding="utf8" ?>
<patient xmlns="http://stackoverflow.com/example">
.....
</patient>
by using code like this:
Message MyRestMethod()
{
Patient patientObject = new Patient() {Name="Mickey Mouse"};
Message message = WebOperationContext.Current.CreateXmlResponse<Patient>(patientObject);
return message;
}
However sometimes, the web service is used by a web browser, and so it would be much nicer if it would return documents like this:
<?xml version="1.0" encoding="utf8" ?>
<?xml-stylesheet type="text/xsl" href="/stylesheet/format.xsl" ?>
<patient xmlns="http://stackoverflow.com/example">
.....
</patient>
I have done some substantial digging around, and can almost do it by deriving my own message and overiding OnWriteBodyContents() to get access to the XmlDictionaryWriter. At this point, I then discovered that WriteProcessingInstruction(name, text) not able to write xml-stylesheet instructions.
More importantly, WCF client code receiving an xml-stylesheet processing instruction also bombs out, so even if you "hack" the stream at the character level to add it, it would need not to be sent to WCF clients...
If anyone has a better suggestion, please let me know...
Having dome some substantial reading on this, the answer is that it is not sensible to add an xml-stylesheet marker in the XML being returned to the WCF client.
The markers are processing instructions, which instruct the interpreter to process the XML document in a certain way. In this particular case by applying an XSLT to the document. the WCF serialisation and deserialiser both reject XML with stylesheet processing instructions, which makes sense - as in the WCF client case you do not want the processing instruction to be followed.
However, for my usecase, having the stylesheet processing instruction in when the xml is returned to a browser does make sense, so I have solved my problem by doing a conditional serialisation based on the UserAgent in the request, and in the case of it not being the WCF client application, I am adding the stylesheet to the stream thats used to create the response message.
In such case you are most probably going to to custom message encoder because xml declaration is added by message encoder and it doesn't provide any features to add any other directives.