XACML Language Structure

This is the second in the series of blog posts that covers the basics of XACML. The previous post covered the XACML reference architecture, specifically looking at the flow of control across the various entities of the architecture (PEP, PDP, PIP, PRP, PAP).

This post will cover the XACML policy language structure and syntax. The full range of discussion on XACML policy specification is beyond the scope of a single blog post. This post attempts to cover the basics and interested readers are encouraged to refer to the XACML standard for in-depth material on this subject.


As can be expected from an Attributed-Based Access Control (ABAC) system, attributes play a central role in XACML. The XACML request sent from the PEP to the PDP captures the deciding attributes related to the initial business request to access the resource. In XACML, attributes are typically grouped into four categories – Subject, Resource, Action and Environment. XACML 3.0 allows users to create their own custom categories too.

On receiving the XACML request, the PDP starts to evaluate the request against policies in its repository and prunes the irrelevant ones by comparing the attribute values present in the request to those specified in the policies’ conditions to make a decision. XACML provides two means for Policies to resolve attribute values from the request – “AttributeDesignator” and “AttributeSelector”. AttributeDesignator allows the policy to specify an attribute with given identifier, category and data type. AttributeSelector on the other hand provides a mean to lookup the value of attributes using a XPath query by specifying the data type and XPath expression. Attribute selectors are then executed against the XML content that may have been sent along in the initial XACML request.

<xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal"> 	<xacml3:AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">raise</xacml3:AttributeValue> 	<xacml3:AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id”  		DataType="http://www.w3.org/2001/XMLSchema#string" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"  		MustBePresent="false"/> </xacml3:Match>

Language Elements

The XACML policy language is made of three core structural elements:

  • PolicySet
  • Policy
  • Rule

The PolicySet can be considered as a container that is used to hold other PolicySet(s), Policies or references to policy sets or policies found in other containers or locations. The Policy consists of one or more rules and as such forms the basic unit that can be acted upon by the PDP. The Rule is the basic building block of a XACML policy: it contains the desired Effect – either Permit or Deny.

A XACML policy file contains one and only one root XML element which can be either a Policy or a PolicySet. This means a Rule cannot live on its own.

The following UML diagram summarizes the relationship between PolicySet, Policy, and Rule.


Combining Algorithms

Because PolicySets can contain one or more Policies or PolicySets, and Policies can contain more than one Rule, it becomes necessary to provide a means to evaluate the decision of each one of these subsets in relation to the others. Imagine for instance a Policy which contains two rules:

Rule 1: managers can view customer records → Permit
Rule 2: no one can access any kind of data before 9am or after 5pm → Deny.

There is a potential conflict between the two rules. What if the requesting user is a manager trying to access a customer record at 3am? Which rule wins?

XACML handles this situation through the concept of Combining Algorithms, which defines how the higher level set should interpret the various decisions made by the underlying unit. PolicySet uses Policy Combining Algorithms while Policy uses Rule Combining Algorithms. “Permit Overrides” is one example of such an combining algorithm which states that if any rule (in the case of a Rule Combining Algorithm) or a policy (in the case of a Policy Combining Algorithm) provides a Permit decision (as opposed to Not Applicable, Indeterminate or Deny), it overrides the decision provided by other rules and policies and a combined decision of Permit is returned.

<xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" PolicyId="60d9c97a" Version="1.0" RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit">

The following combining algorithms are defined in the core XACML 3.0 specification:

Rule combining algorithms

Policy combining algorithms

  • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides

  • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides

  • urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable

  • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-deny-overrides

  • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-permit-overrides

  • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit

  • urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unless-deny

  • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides

  • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides

  • urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable

  • urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable

  • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-deny-overrides

  • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-permit-overrides

  • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit

  • urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny


Since a PolicySet can contain multiple policies and a policy can contain multiple rules, it is essential to specify which policy/rule applies to which request, without which the the PDP would have to parse each and every policy and rule in a set of XACML policies before it can decide whether the XACML request matches the rule. This is done using a Target. It is a set of statements that are associated with category (like Subject, Resource, Action etc.) attributes that must match with that of the XACML request for that specific PolicySet, Policy of Rule to be applicable to the XACML request.

For example, one could write a set of Rules that applies to the resource Purchase Order and add it to a Policy. Then we could specify that the target of that Policy is the resource type ‘Purchase Order’. When the PDP receives the XACML request that contains ‘Purchase Order’ as a resource attribute, the PDP would match it against the target that is specified for the policy and then start parsing the set of Rules contained in the policy for further comparison. The targets within the Rules can be used to further narrow the scope of each of the rules. For example, if Rule 1 only applies to XACML requests with attributes resource type ‘Purchase Order’ and action ‘raise’, the target of Rule 1 will contain a check as follows: action-id == ‘raise’.

<xacml3:Rule     Effect="Permit”    RuleId="http://axiomatics.com/alfa/identifier/com.axiomatics.alfa.tutorial.raisePO">    <xacml3:Description>This rule applies only to raise action</xacml3:Description>    <xacml3:Target>       <xacml3:AnyOf>          <xacml3:AllOf>             <xacml3:Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">                <xacml3:AttributeValue                      DataType="http://www.w3.org/2001/XMLSchema#string">raise</xacml3:AttributeValue>                <xacml3:AttributeDesignator  	AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id” 	DataType="http://www.w3.org/2001/XMLSchema#string"                       Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"                        MustBePresent="false"                 />              </xacml3:Match>           </xacml3:AllOf>        </xacml3:AnyOf>    </xacml3:Target> </xacml3:Rule>


Once a PolicySet/Policy/Rule Target matches the attribute specified in an XACML request, the rule(s) is(are) further evaluated. The core part of the Rule is its Condition. In fact, a Condition can occur only within a Rule. If the Condition evaluates to true, then the Effect (Permit or Deny) associated with the Rule is returned to the parent policy. If an error occurs when a Rule is evaluated, the Effect “Indeterminate” is returned. If none of the conditions are applicable to the request in question, a “NotApplicable” is returned.

While targets are limited in power, one could only match attributes to single constants and was limited to a AND/OR/AND structure, conditions could be used for much more expressive matching and was not limited to AND/OR/AND structure. Conditions can also use non-boolean functions and are also able to match attributes against attributes, not just constant values.

The example below shows a condition that checks if subject’s username is the same as resource’s owner attribute.

<xacml3:Condition>    <xacml3:Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" >       <xacml3:Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">             <xacml3:AttributeDesignator              	AttributeId=”username”             	DataType="http://www.w3.org/2001/XMLSchema#string"             	Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"             	MustBePresent="false” />       </xacml3:Apply>      <xacml3:Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">             <xacml3:AttributeDesignator              	AttributeId=”owner”             	DataType="http://www.w3.org/2001/XMLSchema#string"             	Category="urn:oasis:names:tc:xacml:1.0:subject-category:resource"             	MustBePresent="false” />       </xacml3:Apply>    </xacml3:Apply> </xacml3:Condition>


In this second set of blog posts introducing XACML we looked at the basics of the XACML language construct (PolicySet, Policy and Rule), the concepts of Targets, Conditions and how Attributes are specified in XACML policies for matching with XACML requests.

Related Articles

Meeting today’s dynamic authorization and access challenges: The Axiomatics story | Dynamically Speaking
Dynamically Speaking
For more than 15 years, Axiomatics has worked with companies worldwide to define and deliver solutions to the most complex authorization and access challenge. In...
Getting started with Zero Trust using dynamic authorization | Dynamically Speaking
Dynamically Speaking
Zero Trust. It’s everywhere. It’s a methodology that’s been around for years, and we are now seeing a significant uptick in the number of enterprises...
The case for dynamic authorization in banking and finance
Attribute Based Access Control (ABAC)
More than other organizations, banks, and financial institutions face the highest levels of scrutiny when it comes to how they protect critical assets and sensitive...