How can many complex permit rules for the same XACML policy be managed?
XACML, the eXtensible Access Control Markup Language, is an authorization language that implements Attribute Based Access Control (ABAC). As the name indicates, XACML uses attributes inside policies to convey authorization statements. Policy authoring can be an art form, and we won’t get into every aspect of policy authoring today. For a brief overview of what a policy is, click here.
Using policy structure and combining algorithms to make a policy easier to read
Have you ever found yourself with a long, complex list of permit rules that must all be true for a given resource and action? Or perhaps you have a long list of prerequisite requirements that must be met before evaluating a policy for a specific resource and action. In these cases, all of the targets and conditions must be true in order for a permit decision to be returned. Sure, you can add many targets and conditions to a single rule, but if you have several of them, it can become difficult to understand and/or manage.
This complex blob of targets and conditions can be simplified by adding some policy structure. Along with the use of combining algorithms, this added structure can help organize all of the individual rules in an easy-to-manage-and-read policy. Yes, this structure technically does add some overhead to policy evaluation, but it is doubtful that it would amount to a measurable impact on performance.
Let’s consider the following, somewhat simple, example to help illustrate the concept.
In order for an attorney to view a court reporter’s transcripts, all of the following must be true:
The attorney must be assigned to the case the transcripts are for.
The attorney must currently be practicing and in good standing with the bar.
The attorney must be licensed to practice in the court the case was heard in.
The transcripts need to be paid for.
The policy that has all of these requirements broken down into an easy-to-read structure would look like the example below. For the sake of simplicity, the targets and conditions needed are not shown. It is the structure that is key.
policyset attorneyViewCourtReporterTranscripts{ apply denyOverrides policy attorneyAssignedToCase{ apply denyUnlessPermit rule attorneyAssignedToCase{ permit } } policy practicingAttorneyInGoodStanding{ apply denyUnlessPermit rule practicingAttorneyInGoodStanding{ permit } } policy licensedToPracticeInCourtTranscriptWasCreatedIn{ apply denyUnlessPermit rule licensedToPracticeInCourtTranscriptWasCreatedIn{ permit } } policy checkCleared{ apply denyUnlessPermit rule checkCleared{ permit } } }
In the above example, all of the rules must be true in order for an attorney to be able to view the transcript for a case. If any one of these rules is not true, then the “denyUnlessPermit” combining algorithm of the policy object will return “deny” and the “denyOverrides” on the “attorneyViewCourtReporterTranscripts” policy set will override any of the rules that returned “permit.” It’s the use of the combining algorithms that ties this structure together. More on combining algorithms can be found here.
Graphically, this policy would look like:

Conclusion
If you find yourself needing to put many targets and conditions into one rule, where all must be true in order to return a permit decision, you don’t have to put them all in the same rule. By adding policy structure and breaking the requirements out into their own individual rules, it makes the policy much easier for us humans to read and to make changes if necessary.
The “Question of the Week” – an ongoing feature that will tackle technical and usage questions. We’ll have input from our sales engineers and customer relations teams. If you have a question to consider, please send it to webinfo@axiomatics.com.