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.
Related
I like to use the correct HTTP methods when I'm creating an API. And usually it's very straightforward. POST for creating entities, PUT for updating them, GET for retrieving etc.
But I have a use-case here where I will create an endpoint that updates the status of multiple objects given 1 identifier.
e.g.:
/api/v1/entity/update-status
But note that I mentioned multiple objects. The initial thought of my team would be to use map it as POST, but it won't actually be creating anything, plus if you were to call the same endpoint multiple times with the same identifier, nothing would change after the first time. Making it idempotent.
With this in mind, my idea was to create it as a PUT or even PATCH endpoint.
What do you smart people think?
I imagine PATCH would be the most correct way. Although if you use a PUT it would also not be incorrect.
The difference between the PUT and PATCH requests is reflected in the
way the server processes the enclosed entity to modify the resource
identified by the Request-URI. In a PUT request, the enclosed entity
is considered to be a modified version of the resource stored on the
origin server, and the client is requesting that the stored version be
replaced. With PATCH, however, the enclosed entity contains a set of
instructions describing how a resource currently residing on the
origin server should be modified to produce a new version. The PATCH
method affects the resource identified by the Request-URI, and it also
MAY have side effects on other resources; i.e., new resources may be
created, or existing ones modified, by the application of a PATCH.
Whilst it is a convention in REST APIs that POST is used to create a resource it doesn't necessarily have to be constrained to this purpose.
Referring back to the definition of POST in RFC 7231:
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
Providing a block of data, such as the fields entered into an HTMl form, to a data-handling process
Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
*Creating a new resource that has yet to be identified by the origin server; and *
Appending data to a resource's existing representation(s).
Clearly creation is only one of those purposes and updating existing resources is also legitimate.
The PUT operation is not appropriate for your intended operation because again, per RFC, a PUT is supposed to replace the content of the target resource (URL). The same also applies to PATCH but, since it is intended for partial updates of the target resource you can target it to the URL of the collection.
So I think your viable options are:
POST /api/v1/entity/update-status
PATCH /api/v1/entity
Personally, I would choose to go with the PATCH as I find it semantically more pleasing but the POST is not wrong. Using PATCH doesn't gain you anything in terms of communicating an idempotency guarantee to a consumer. Per RFC 5789: "PATCH is neither safe nor idempotent" which is the same as POST.
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.
Is there a way in mule to specify a configuration reference dynamically?
instead of having:
<a:connector config-ref="the_config_name" other-properties="here" />
Something like the following?
<a:connector config-ref="#[flowVars.configName]" other-properties="here" />
This is needed because the configuration used has some properties (URL) that does not allow dynamic values since they are instantiated at the start of the mule app.
No, config-refs are static. Instead, configurations themselves can be dynamic in Mule 4. This requires special handling of the parameters so that then can be re instantiated per configuration.
For more information on this, you can take a look here.
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
We have a WCF service that needs to be deployed to 200 plus customers' servers. We would like to be able to make a portion of the web.config available for customization by using the configSource attribute like so:
<bindings configSource="bindings.config" />
This allows us to overwrite the main web.config file with future upgrades while not overwriting customers' own modifications to the sections that we decide to externalize this way. Unfortunately, there's a problem with this - according to this article, "When you use the configSource attribute, you must move the entire section to a separate file because there is no merging of element settings." This means that any section we put in an external file is now outside of our reach for upgrades and changes without having to mess with the external files that the customer may have made modifications to.
Is there any way around this? Can we have our cake and eat it too, or do we have to decide between having control ourselves and giving our customers flexibility?
Well it appears there's no way around this, you can only do it one way or the other. In the end the decision we made was to use configSource and externalize certain portions of the web.config, knowing that those would be outside of our control but that the vast majority of our web.config would still be available for future modifications.