A beginner’s guide to XACML

Published in

Identity Beyond Borders

8 min readMay 8, 2020

Today, enterprise applications seek ways of enforcing security that allows the right people to access the right resources with restrictions enforced by enterprise policies. The identity and entitlement management systems reduce the burden of enterprise architects and developers in security- related implementations.

Attribute-Based Access Control (ABAC) is an access control paradigm whereby access rights are granted to users through the use of policies that combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes, etc.). This model supports Boolean logic, in which rules contain “IF, THEN” statements about who is making the request, the resource, and the action.
For example: IF the requestor is a manager, THEN allow read/write access to sensitive data.

Role-based Access Control (RBAC) is an approach used to restrict access to authorized users based on their role. This is a static permission model which provides access control. This access control type is used when all users are categorized into different roles. The roles define the resources that can be accessed by users assigned to that role. This type of access control reduces management overhead.

What is XACML?

XACML (eXtensible Access Control Markup Language) is an XML-based language for access control that has been standardized by the Technical Committee of the OASIS consortium. XACML is popular as a fine grain authorization method among the community. XACML describes both an access control policy language, request/response language and reference architecture. The policy language is used to express access control policies (who can do what when). The request/response language expresses queries about whether a particular access should be allowed (requests) and describes answers to those queries(responses). The reference architecture proposes a standard for deployment of necessary software modules within an infrastructure to allow efficient enforcement of policies.

XACML supports Attribute-Based Access Control (ABAC) and evaluation can be done with the additional data retrieved from Policy Information Point (PIP) which is defined by the XACML reference architecture.

XACML Architecture

Policy Decision Point (PDP) evaluates policies against access requests provided by Policy Enforcement Points (PEP). To provide the decisions, PDP may also need to query a Policy Information Point (PIP) to gather descriptive attributes about the user or any other missing attribute in the request. Policy Administration Point (PAP) is used to manage the PDP and PIP functionality.

XACML policy language structure and syntax

Three top-level policy elements

<Rule>: contains a Boolean expression that can be evaluated in isolation, but that is not intended to be accessed in isolation by a PDP. So, it is not intended to form the basis of an authorization decision by itself. It is intended to exist in isolation only within an XACML PAP, where it may form the basic unit of management
<Policy>: contains a set of <Rule> elements and a specified procedure for combining the results of their evaluation. It is the basic unit of the policy used by the PDP, and so it is intended to form the basis of an authorization decision
<PolicySet>: contains a set of <Policy> or other <PolicySet> elements and a specified procedure for combining the results of their evaluation.

The diagram below shows the XACML policy model.

Let’s take a closer look at each of these components.

Target

An XACML <PolicySet>, <Policy> or <Rule> element contains a <Target> element that specifies the set of requests to which it applies.

An empty <Target> matches any request. Otherwise, target value is “Match” if all the specified “AnyOf”s are matched in the request. Following tables show how the target evaluation is done based on <AnyOf>,<AllOf> and <Match>.

Example:

If the target should be matched,

if the conditionA and conditionB is matched,

<Target>
   <AnyOf>
      <AllOf>
         <Match>conditionA</Match>
         <Match>conditionB</Match>
      </AllOf>
   </AnyOf>
</Target>

if the conditionA or conditionB is matched,

<Target>
   <AnyOf>
      <AllOf>
         <Match>conditionA</Match>
      </AllOf>
      <AllOf>
         <Match>conditionB</Match>
      </AllOf>
   </AnyOf>
</Target>

Sample,

<Target>
      <AnyOf>
         <AllOf>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Pamoda</AttributeValue>
               <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
            </Match>
            <Match MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
               <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">GET</AttributeValue>
               <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
            </Match>
         </AllOf>
      </AnyOf>
   </Target>

In the above Target definition, the target will validate whether the subject of the request is “Pamoda” and the action is “GET”

Rule-combining algorithms

The rule-combining algorithm specifies the procedure by which the results of evaluating the component rules are combined when evaluating the policy.

Some examples of standard combining algorithms are :

Deny-overrides (urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides)
— If any decision is “Deny”, the result is “Deny”.
Permit-overrides (urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides)
— If any decision is “Permit”, the result is “Permit”.
First-applicable (urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable)
— Each rule is evaluated in the order in which it is listed in the policy. For a particular rule, if the target matches and the condition evaluates to Permit, Deny, or Indeterminate corresponding effect of the rule SHALL be the result of the evaluation of the policy. Otherwise, return to the next rule.

Rule

A rule is the most elementary unit of policy. The heart of most of the rules is a Condition, which is a boolean function. If the condition evaluates to true, then the Rule’s Effect is returned. A Condition can be quite complex, built from an arbitrary nesting of non-boolean functions and attributes. The following table shows how the final effect of the rule is decided.

Attributes, Attribute Values, and Functions

As XACML is used in Attribute-Based Access Controlling, in XACML all the attributes are categorized into four main categories. But from XACML 3.0, custom categories are also supported.

Subject (urn:oasis:names:tc:xacml:3.0:attribute-category:subject)
Resource (urn:oasis:names:tc:xacml:3.0:attribute-category:resource)
Action (urn:oasis:names:tc:xacml:3.0:attribute-category:action)
Environment (urn:oasis:names:tc:xacml:3.0:attribute-category:environment)

A Policy resolves attribute values from the request or retrieves values from the PIP.

<AttributeDesignator>: lets the policy specify an attribute with a given name and type, and optionally an issuer as well. <AttributeDesignator> can return multiple values. XACML provides a special attribute type called a “Bag”.

<AttributeValue>: contains a literal attribute value

XACML comes with a powerful system of functions. Functions can work on any combination of attribute values and can return any kind of attribute value supported in the system. Functions can also be nested, so we can have functions that consume the output of other functions, and this hierarchy can be arbitrarily complex.

<Apply>: denotes the application of a function to its arguments, thus encoding a function call.

💡 NOTE: The XACML functions may consume different types and different numbers of attributes as inputs depending on the function definition. Some of the functions may consume a bag of attributes while some require a single attribute. Therefore before using the functions, we need to study the behavior.

Let’s take consider an example rule, where the request is permitted if only the request is performed by a user named “Pamoda”.

<Rule Effect="Permit" RuleId="rule1">
      <Condition>
         <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
            <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-one-and-only">
               <AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true"/>
            </Apply>
            <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Pamoda</AttributeValue>
         </Apply>
      </Condition>
   </Rule>

In the sample rule,

If the condition given in the rule is successfully validated, the effect will be “Permit”
The function “urn:oasis:names:tc:xacml:1.0:function:string-equal” is used for the comparison. This function takes two arguments of type “http://www.w3.org/2001/XMLSchema#string”
<AttributeDesignator> selects a bag of type “http://www.w3.org/2001/XMLSchema#string”
The function “urn:oasis:names:tc:xacml:1.0:function:string-one-and-only” guarantees that its argument evaluates to a bag containing exactly one value.
<AttributeValue> defines the second attribute for the comparison.

Obligation and Advice Expressions.

A rule, policy, or policy set may contain one or more obligation or advice expressions. When such a rule, policy, or policy set is evaluated, the obligation or advice expression will be evaluated to an obligation or advice respectively, which is passed up to the next level of evaluation only if the result of the rule, policy, or policy set being evaluated matches the value of the FulfillOn attribute of the obligation or the AppliesTo attribute of the advice.

Advice is similar to obligation and it shares much of its syntax. The difference is contractual: the PEP can disregard any advice it receives. PEPs do not have to comply with advice statements; PEPs can consider or discard the statement.

Example for Obligation,

<ObligationExpressions>
  <ObligationExpression FulfillOn="Permit" ObligationId="email_obligation">
    <AttributeAssignmentExpression AttributeId="email">
       <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">pamodaaw@gmail.com</AttributeValue>
    </AttributeAssignmentExpression>
  </ObligationExpression>
</ObligationExpressions>

Response after evaluating the policy with the above obligation.

<Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Result>
    <Decision>Permit</Decision>
    <Status>
      <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    </Status>
    <Obligations>
       <Obligation ObligationId="email_obligation">
         <AttributeAssignment AttributeId="email" DataType="http://www.w3.org/2001/XMLSchema#string">
pamodaaw@gmail.com</AttributeAssignment>
       </Obligation>
    </Obligations>
  </Result>
</Response>

In the above Obligation expression,

the obligation will be added to the response when only the decision is “Permit”
The obligation value, “pamodaaw@gmail.com” is added to the response as defined in the policy.

Example for Advice Expression

<AdviceExpressions>
      <AdviceExpression AdviceId="email_advice" AppliesTo="Permit">
         <AttributeAssignmentExpression AttributeId="email">
            <AttributeDesignator AttributeId="http://wso2.org/claims/emailaddress" Category="urn:oasis:names:tc:xacml:3.0:subject-category:access-subject"
DataType="http://www.w3.org/2001/XMLSchema#string" MustBePresent="true">
            </AttributeDesignator>
         </AttributeAssignmentExpression>
      </AdviceExpression>
   </AdviceExpressions>

Response after evaluating the policy with the above obligation.

<Response xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17">
  <Result>
    <Decision>Permit</Decision>
    <Status>
      <StatusCode Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
    </Status>
    <AssociatedAdvice>
      <Advice AdviceId="email_advice" >
         <AttributeAssignment  AttributeId="email" DataType="http://www.w3.org/2001/XMLSchema#string">
pamoda@wso2.com</AttributeAssignment>
      </Advice>
    </AssociatedAdvice>
  </Result>
</Response>

In the above Advice expression,

the advice will be added to the response when only the decision is “Permit”
In contrast to the obligation definition, here I have taken the advice return value from the user’s email claim. So that we can get dynamic values based on the user.

Putting it Together: An Example Policy

Please note that I have used the WSO2 Identity Server for trying out the XACML Policies.

Policy definition,

<Target>: policy is applied only if subject=“pamoda” and action=“GET”
<Rule>: Permits if the subject-id is equal “Pamoda”
<Obligation>: Returns the value “pamodaaw@gmail.com” if the rule is Permit
<Advice>: Returns the value of the user claim, “http://wso2.org/claims/emailaddress” if the rule is Permit.

Sample Request

Sample Response

References

eXtensible Access Control Markup Language (XACML) Version 3.0

Access Performing an action Access control Action An operation on a resource Advice Applicable policy Attribute…

docs.oasis-open.org

Identity & Access Management - On-Premise and in the Cloud

Industry Recognition WSO2 Identity Server APIs shows strength in interoperability with a large number of other IAM…

wso2.com

https://is.docs.wso2.com/en/latest/get-started/access-control-and-entitlement-management/#xacml-system-architecture

I hope that you could learn something from this blog. If you have any concerns, please add a comment.

Happy Reading!!!

My other blogs on XACML: