XACML

The eXtensible Access Control Markup Language is an XML-based standard markup language for specifying access control policies. The standard, published by OASIS, defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.
XACML is primarily an attribute-based access control system. In XACML, attributes - information about the subject accessing a resource, the resource to be addressed, and the environment - act as inputs for the decision of whether access is granted or not. XACML can also be used to implement role-based access control.
In XACML, access control decisions to be taken are expressed as Rules. Each Rule comprises a series of conditions which decide whether a given request is approved or not. If a Rule is applicable to a request but the conditions within the Rule fail to evaluate, the result is Indeterminate. Rules are grouped together in Policies, and a PolicySet contains Policies and possibly other PolicySets. Each of these also includes a Target, a simple condition that determines whether it should be evaluated for a given request. Combining algorithms can be used to combine Rules and Policies with potentially differing results in various ways. XACML also supports obligations and advice expressions. Obligations specify actions which must be executed during the processing of a request, for example for logging. Advice expressions are similar, but may be ignored.
XACML separates access control functionality into several components. Each operating environment in which access control is used has a Policy Enforcement Point which implements the functionality to demand authorization and to grant or deny access to resources. These refer to an environment-independent and central Policy Decision Point which actually makes the decision on whether access is granted. The PDP refers to policies stored in the Policy Retrieval Point. Policies are managed through a Policy Administration Point.
Version 3.0 was ratified by OASIS in January 2013.

History

Version 1.0 was ratified by OASIS standards organization in 2003.
Version 2.0 was ratified by OASIS standards organization on February 1, 2005.
Version 3.0 was ratified by OASIS in January 2013.

Architecture

Terminology

Non-normative terminology

Abbr.	Term	Description
PAP	Policy Administration Point	Point which manages access authorization policies
PDP	Policy Decision Point	Point which evaluates access requests against authorization policies before issuing access decisions
PEP	Policy Enforcement Point	Point which intercepts user's access request to a resource, makes a decision request to the PDP to obtain the access decision , and acts on the received decision
PIP	Policy Information Point	The system entity that acts as a source of attribute values
PRP	Policy Retrieval Point	Point where the XACML access authorization policies are stored, typically a database or the filesystem.

Flow

A user sends a request which is intercepted by the Policy Enforcement Point
The PEP converts the request into a XACML authorization request
The PEP forwards the authorization request to the Policy Decision Point
The PDP evaluates the authorization request against the policies it is configured with. The policies are acquired via the Policy Retrieval Point and managed by the Policy Administration Point. If needed it also retrieves attribute values from underlying Policy Information Points.
The PDP reaches a decision and returns it to the PEP
Policy elements

Structural elements

XACML is structured into 3 levels of elements:

PolicySet,
Policy,
Rule.

A policy set can contain any number of policy elements and policy set elements. A policy can contain any number of rule elements.

Attributes and categories

Policies, policy sets, rules and requests all use subjects, resources, environments, and actions.

A subject element is the entity requesting access. A subject has one or more attributes.
The resource element is a data, service or system component. A resource has one or more attributes.
An action element defines the type of access requested on the resource. Actions have one or more attributes.
An environment element can optionally provide additional information.
Targets

XACML provides a target, which is basically a set of simplified conditions for the subject, resource, and action that must be met for a policy set, policy, or rule to apply to a given request. Once a policy or policy set is found to apply to a given request, its rules are evaluated to determine the access decision and response.
In addition to being a way to check applicability, target information also provides a way to index policies, which is useful if you need to store many policies and then quickly sift through them to find which ones apply. When a request to access that service arrives, the PDP will know where to look for policies that might apply to this request because the policies are indexed based on their target constraints. Note that a target may also specify that it applies to any request.
Policy set, policy and rule can all contain target elements.

Conditions

Conditions only exist in rules. Conditions are essentially an advanced form of a target which can use a broader range of functions and more importantly can be used to compare two or more attributes together, e.g. subject-iddoctor-id. With conditions, it is possible to implement segregation of duty checks or relationship-based access control.

Obligations & Advice

Within XACML, a concept called obligations can be used. An obligation is a directive from the policy decision point to the policy enforcement point on what must be carried out before or after an access is approved. If the PEP is unable to comply with the directive, the approved access may or must not be realized. The augmentation of obligations eliminates a gap between formal requirements and policy enforcement. An example of an obligation could look like this:
Access control rule:
Allow access to resource MedicalJournal with attribute patientID=x
if Subject match DesignatedDoctorOfPatient
and action is read
with obligation
on Permit: doLog_Inform
on Deny : doLog_UnauthorizedLogin
The XACML's obligation can be an effective way to meet formal requirements that can be hard to implement as access control rules. Furthermore, any formal requirements will be part of the access control policy as obligations and not as separate functions, which makes policies consistent and centralization of the IT environment easier to achieve.
Obligations can be used for "break-the-glass" scenarios or trust elevation.
In addition to obligations, XACML supports advice which are identical to obligations with the difference that a PEP is not obligated to enforce the advice.

Combining algorithms

What happens in XACML if there are two rules that contradict each other? Imagine for instance a first rule that would say managers can view documents and a second rule that would say no one can work before 9am. What if the request is about Alice trying to view a document at 8am? Which rule wins? This is what combining algorithms tell us. They help resolve conflicts.
XACML defines a number of combining algorithms that can be identified by a RuleCombiningAlgId or PolicyCombiningAlgId attribute of the or elements, respectively. The rule-combining algorithm defines a procedure for arriving at an access decision given the individual results of evaluation of a set of rules. Similarly, the policy-combining algorithm defines a procedure for arriving at an access decision given the individual results of evaluation of a set of policies.

Functions

XACML defines a long list of functions to manipulate and compare attributes to other attributes and values:

Equality, inequality and other matching functions
Arithmetic functions
String functions
Logical functions
Set and bag functions
Higher order functions
Regular expression functions
XPath functions

The functions and their identifiers are fully described in the standard. Functions are type-specific i.e. there is a function for string equality and a different one for integer equality.

Equality, inequality and other matching functions

Arithmetic functions

Refer to the standard for a formal definition of these function.

add
subtract
multiply
divide
mod
abs
round
floor
String functions

Refer to the standard for a formal definition of these function.

string-concatenate
string-starts-with
string-ends-with
string-contains
string-substring
Logical functions (and, or, not)

Set and bag functions

Regular expression functions

XPath functions

Higher order functions

The list of higher order functions is as listed below. For a formal definition, refer to the XACML standard.

anyOf
* parameters: anyAtomicOrBag anyAtomicOrBag*
* return value: boolean
* Description: this function takes in a Boolean function and 2 or more attribute values or bags. The higher-order function applies the Boolean function to the remaining parameters.
* Example: anyOf will return true if role is single-valued, there is at least one value in the attribute bag allowedRoles equal to the value inside the single-valued attribute bag role.
allOf
* parameters: anyAtomicOrBag anyAtomicOrBag*
* return value: boolean
anyOfAny
* parameters: anyAtomicOrBag anyAtomicOrBag*
* return value: boolean
allOfAny
* parameters: bag bag
* return value: boolean
anyOfAll
* parameters: bag bag
* return value: boolean
allOfAll
* parameters: bag bag
* return value: boolean
map
* parameters: anyAtomicOrBag anyAtomicOrBag*
* return value: bag