Optimize way to Match Policies in the PDP in a Distributed Environment

Question

Hi I have gone through many use cases regarding XACML , but i don't know what is the best way to load policies in the PDP. As per the PDP workflow defined by the OASIS i understood that when the incoming request will come to the PDP . PDP is responsible for matching the corresponding policies based on request.

Since PDP is going to match each and every policy , just think about a scenario where i have 10,000 policies stored in a distributed environment what will happen that time. It is going to consume more and more time in matching , that's not an efficient way of matching the policy.

I need some clarifications on this issues:

1. How to distribute the policy on different servers ?

2. If I distribute the policy on different servers then how my PDP will recognize and fetch the corresponding policy from the particular server?

3. What is the best way by which PDP will recognize the exact policy to match with the incoming request?

Answer 1

Yes.. If there are 10,000 policies stored, there can be considerable time to match them..

If you think about Horizontal scaling, You can still look for following...

1. Caching all policies or Target elements
2. Making target to be not complex (Just some String match)
3. Parallel matching of policies with multiple threads.

I agree that, for 10000 policies, we may need to look for Vertical scaling.. I assume, you have defined policies based on the applications. Application id can be the Target element of your policies. (It can be any thing that helps to create a policy collection). If I answer your questions

1. Policies can distributed based on Target element (based the application). Therefore different servers has different policies based on the application id. Basically it is like one PDP for application. (Idea is to you want to group the policies based on some way.. that can distributed them in to separate PDPs)
2. There can be a central PDP hub, Once request is received it, It would check for application id and route message to relevant PDP. Sometime, It does not want to be a PDP, some routers (such as ESB) which can look for some parameter in the request and send in to the relevant PDP.
3. As mentioned.. It is better to have central server that route the requests

Also, If you do not achieve parallel evaluation of distributed policies.. It also can be done with PDP hub... Say, you can distribute your policies in to 10 PDPs and there is PDP hub. Once request is received for PDP hub, It would send request to 10 PDPs.. and 10 PDP would evaluate policies parallel. Once response are received to PDP hub, It can aggregated he results of 10 PDP and send the final result to PEP.

Answer 2

The syntactical way to handle situations where you have huge number of (10,000) policies is to use the "Target" clause available at PolicySet, Policy and Rule level as judiciously as possible so as to prune the decision tree as quickly as possible.

So suppose you know that out of the 10,000 policies only 1000 are for the finance department operations, one could add a resource category attribute "dept-focus" and we prune the tree by checking

target: resource.dept-focus == "finance"

Once that gets you into a pruned tree, if you know that the finance department policies relate to 5 different applications (and maybe some common dept.-wide policies), you could then prune using a "app-id" attribute and so on.

Of course for this to work, the PEPs need to add the appropriate value of these attribute ids into the XACML request.

A more deployment-centric solution would be to split the 10,000 policies into smaller chunks that are then deployed into separate PDP groups. Various vendors use various names for such concepts (if available). Axiomatics, for whom I work for, calls these authorization domains.

So you could deploy all the policies associated with the finance department into a set of PDPs that make up the "Finance" authz. domain and another set into the R&D domain etc. These PDPs in the same domain can of course be load-balanced. Management can become a bit hairy if there is no central controller for these domains, something like the Axiomatics Services Manager.

Hope that helps.