The eXtensible Access Control Markup Language (XACML) 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 policy language, but it also defines syntaxes for the requests sent by the Policy Enforcement Point to the Policy Decision Point, also called authorization decision requests. The response process follows the aforementioned request flow in reverse. In XACML, attributes—information about the subject accessing a resource, the resource to be addressed, the action to be performed on the resource, and the environment—act as inputs deciding whether access is granted or not. XACML can also be used to implement role-based access control.

In XACML, Rules specify the conditions under which an access request is approved (Permit) or rejected (Deny). 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 combined according to a combining algorithm defined by the parent Policy (e.g., deny-unless-permit, permit-unless-deny). Then, Policies may be grouped together in a larger Policy (or PolicySet in XACML 3.0) and combined according to its combining algorithm similarly.

Policies include a Target, which is a condition that determines whether that Policy should be evaluated for a given request. Policies and Rules also include obligations and advice expressions. Obligations specify actions that must be executed during the processing of a request (e.g., for logging). Advice expressions are similar but may be ignored..

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 4.0 (Committee Specification Draft 01) was published by OASIS in February 2026.

Architecture

Terminology

Non-normative terminology (following <nowiki>RFC 2904</nowiki>, except for PAP)

{| class="wikitable"

!Term

!Description

|-

|Policy Administration Point (PAP)

|Point that manages access authorization policies

|-

|Policy Decision Point (PDP)

|Point that evaluates access requests against authorization policies before issuing access decisions

|-

|Policy Enforcement Point (PEP)

|Point that intercepts a user's access request to a resource, requests an access decision from the PDP (i.e., whether access to the resource is approved or rejected), and acts on the received decision

|-

|Policy Information Point (PIP)

|System entity that acts as a source of attribute values (e.g., a resource, subject, environment)

|-

|Policy Retrieval Point (PRP)

|Point where the XACML access authorization policies are stored—typically a database or the filesystem.

|}

Flow

alt=This image shows the XACML architecture and a sample authorization flow.|thumb|This image shows the XACML architecture and a sample authorization flow.

  1. A user sends a request to access a resource; this request is intercepted by the Policy Enforcement Point (PEP).
  2. The PEP converts the request into a XACML authorization request.
  3. The PEP forwards the authorization request to the Policy Decision Point (PDP).
  4. The PDP evaluates the authorization request against its configured policies. The policies are acquired via a Policy Retrieval Point (PRP) and managed by a Policy Administration Point (PAP). If needed, the PDP also retrieves attribute values from underlying Policy Information Points (PIP).
  5. The PDP reaches a decision (Permit, Deny, NotApplicable, or Indeterminate) and returns it to the PEP.
  6. The PEP enforces the access decision against the user's request.

Policy elements

Structural elements

XACML is structured into the following levels of elements:

  • PolicySet (replaced with/merged into Policy in XACML 4.0),
  • Policy,
  • Rule.

Up to XACML 3.0, a PolicySet can contain any number of PolicySet and/or Policy elements, and a Policy can contain any number of Rule elements.

In XACML 4.0, a Policy can contain any number of Policy and/or Rule elements. There is no longer a distinction between Policy and PolicySet distinction.

Attributes and categories

Policies, 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 what the subject is requesting to access, e.g. some 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 that is not specific to the subject, resource or action, but still in the context of the access request, e.g. the current date/time.

Targets

XACML provides a target, which is basically a condition about the attributes of the subject and/or resource and/or action and/or environment that must be met for a policy or rule to apply to a given request. Once a policy 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.

Policies and rules can all contain target elements.

Conditions

Conditions only exist in Rules. Conditions are essentially boolean expressions that can use AND, OR, NOT operators and a broad range of functions that can be used to compare two or more attributes together, e.g. subject-id==doctor-id.

Up to XACML 3.0, Conditions are a more advanced form of Targets, whereas in XACML 4.0 they are the same. as other ACAL representations such as JACAL simplifies the integration between the PEP and the PDP.

XACML and other standards

XACML and Open Policy Agent

XACML is almost entirely a policy definition language based on XML, defined by an open OASIS specification. The XACML specification  does not cover the design or implementation of Policy Decision Point (PDP), only the policy language they consume. Many proprietary and open-source PDPs use XACML as their policy definition language.

Open Policy Agent (OPA) is an open-source Policy Decision Point (PDP) implementation, capable of interpreting policy language to render policy decisions. OPA is a general-purpose PDP implementation which can be used for any scenario where a policy decision is required, much like PDP implementations that support the XACML specification.

OPA's policy definition language is (Rego), which is a JSON-based, Turing-incomplete language based on Datalog.

The project xacml-with-opa shows how to support the JSON Profile of XACML 3.0