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
Related
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.
I'd like to control how many threads can be used by a web application.
So far I thought it can be set by creating an application-scope workmanager (Deployments -> [application] -> Configuration -> Workload) and setting the Maximum Thread Constraint.
However recently I have the feeling that it is not true as this workmanager should be referenced from the code so it has to be used explicitly from the application.
What I'd need is to configure that from now on the XYZ application can use max 5 threads but no more. It can be done on global level but I want to control only one application.
As far as I know, if you define the workmanager in app's weblogic.xml or weblogic-application.xml, it's for sure will work on application level instead of config.xml which is domain-level config.
If you create and configurate the workmanager's max-threads-constraint and then reference to it in your app’s web.xml file like this:
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>your_workmanager_name</param-value>
</init-param>
i'm pretty sure, that this constraint will apply only on certain app's level.
I have the feeling that it is not true as this workmanager should be referenced from the code so it has to be used explicitly from the application.
Where'd you find this? I may be wrong but I never heard or read that it should be referenced explicitly from code instead of xml.
For more details take a look on this and this in case you hadn't.
I have a Gemfire server region (distributed) and a local region (caching proxy) configured this way:
<client-cache>
<pool name="client" subscription-enabled="true">
<locator host="localhost" port="13489" />
</pool>
<region name="customers" refid="CACHING_PROXY">
<region-attributes>
<subscription-attributes interest-policy="all"/>
<!--<subscription-attributes interest-policy="cache-content"/>-->
</region-attributes>
</region>
</client-cache>
When I'm getting a value from a client region and the key is unknown on the client - it is fetched from the server. After that, however, if the server value changes - the new value is not propagated to client, even when subscription-attributes are set.
What is the misconfiguration here?
To have all changes pushed into your local cache you would need to remove the subscription attributes tag and instead, leave subscription-enabled=true on the pool, and then programmatically call the region.registerInterest API GemFire JavaDoc to actually cause the server to start delivering change notifications to your client.
As a good starting point, I would suggest
region.registerInterestRegex(".*", InterestResultPolicy.NONE, false, false)
This will ensure that you only receive "fresh" values and will take advantage of local cache for repeated retrievals but will not attempt to put all values in memory. However, there are quite a few options for interest registration so you will want to consult the javadoc.
As an additional note, CACHING_PROXY is often combined with some eviction mechanism to ensure that the size of the local cache does not grow indefinitely.
Also, the subscription attributes inside the region tag actually apply to server side configuration, not the client side. Even on the server side it is not ususally necessary to configure the subscription-attributes because the server side region shortcuts (PARTITION, REPLICATE, etc. ) generally configure them appropriately.
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.
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.