Skip to main content
Identity Authority
Category: Access Control Models

eXtensible Access Control Markup Language

Also known as: XACML, XACML 3.0
Simply put

XACML is a standardized, XML-based language for writing and evaluating access control policies that decide whether a request to perform an action should be permitted or denied. It lets organizations express authorization rules in a common format that different systems can share and enforce. It is an authorization mechanism and does not itself authenticate users.

Formal definition

XACML is an OASIS-standardized, XML-based policy language for representing, exchanging, and evaluating fine-grained authorization policies, first made available in 2003 with XACML 3.0 as a later core specification revision. It defines a syntax and framework for expressing access control rules and is commonly used to implement attribute-based access control (ABAC), where authorization decisions are based on attributes of the subject, resource, action, and environment. XACML also describes a reference architecture and evaluation model in which a Policy Decision Point (PDP) evaluates requests against policies and returns a decision; per the evidence, it addresses concerns such as how a PDP should handle multiple attribute values. XACML governs authorization (what a principal may do) and does not perform identification or authentication. Note that specific PDP/PEP/PIP deployment behavior depends on the implementing product and configuration, which is out of scope for the language standard itself.

Why it matters

XACML addresses a persistent problem in identity and access management: authorization logic tends to be scattered across applications, hardcoded into business logic, and inconsistently enforced. By providing an OASIS-standardized, XML-based language for expressing access control policies, XACML lets organizations externalize authorization decisions from individual applications and express rules in a common format that multiple systems can share and evaluate. This separation of policy from code is valuable for consistency, auditability, and the ability to change access rules without rewriting applications.

As the recognized standard language for implementing attribute-based access control (ABAC), XACML matters most where fine-grained, context-aware authorization is required, where a simple role check is insufficient and decisions must weigh attributes of the subject, resource, action, and environment. Because the language is standardized rather than vendor-proprietary, policies can in principle be exchanged and interpreted across conforming implementations, which supports interoperability goals in heterogeneous environments.

It is important to keep XACML's scope precise: it governs authorization, what a principal may do, and does not perform identification or authentication. Verifying who a user is remains a separate concern handled by other mechanisms. XACML's value lies in structuring the decision of whether a given request should be permitted or denied, not in establishing the identity that the request is attributed to.

Who it's relevant to

Security architects
Architects designing centralized, externalized authorization benefit from XACML as a standardized way to separate access control policy from application code. It is particularly relevant when designing ABAC systems that require fine-grained, attribute-driven decisions, and when interoperability across heterogeneous systems is a goal. Architects should remember that XACML addresses authorization only and must be paired with separate authentication mechanisms.
IAM engineers
Engineers implementing authorization need to understand XACML's evaluation model, in which a PDP evaluates requests against policies and returns a decision. Practical work includes authoring policies, handling cases such as multiple attribute values through the language's provided functions, and integrating enforcement points. Note that specific PDP, PEP, and PIP deployment behavior depends on the implementing product and configuration rather than the language standard itself.
Compliance and governance leads
Because XACML externalizes authorization rules into a shared, standardized format, it can support auditability and consistent enforcement of access policies across systems. This is useful for demonstrating how permit or deny decisions are made. Governance teams should distinguish this runtime authorization concern from identity governance activities such as provisioning and access certification, which XACML does not address.

Inside XACML

PDP (Policy Decision Point)
The component that evaluates access requests against applicable policies and returns a decision. In XACML this is the runtime enforcement element that produces a Permit, Deny, Indeterminate, or Not Applicable result.
PEP (Policy Enforcement Point)
The component that intercepts a subject's access request, converts it into an XACML request, forwards it to the PDP, and enforces the returned decision. It sits inline with the protected resource.
PIP (Policy Information Point)
The source that supplies attribute values (about subject, resource, action, or environment) needed by the PDP during evaluation when they are not already present in the request context.
PAP (Policy Administration Point)
The component where policies are authored and managed, making them available to the PDP for evaluation. This is an administration concern distinct from runtime decision-making.
Policy and PolicySet structure
XACML organizes rules hierarchically: rules combine into policies, and policies combine into policy sets. Combining algorithms (for example deny-overrides or permit-overrides) determine how conflicting results are reconciled.
Request/Response context
The standardized representation of an access query and its result, describing the subject, resource, action, and environment attributes evaluated by the PDP and the decision returned to the PEP.
Attribute-based evaluation
XACML is an attribute-based access control (ABAC) language, expressing authorization decisions as functions of subject, resource, action, and environment attributes rather than fixed role assignments.
Obligations and advice
Directives returned alongside a decision that the PEP must fulfill (obligations) or may consider (advice), such as logging an access event or displaying a notice, depending on the profile and implementation.

Common questions

Answers to the questions practitioners most commonly ask about XACML.

Is XACML an authentication protocol?
No. XACML is an authorization standard, not an authentication protocol. It defines how to express access control policies and how to evaluate access requests against them; it does not verify who a principal is. Authentication must be handled separately (for example by an OIDC or SAML flow), and the resulting authenticated identity and its attributes are typically what an XACML policy then evaluates when making an authorization decision.
Does using XACML mean you are locked into RBAC?
No. XACML is most commonly associated with attribute-based access control (ABAC), because it evaluates decisions based on attributes of the subject, resource, action, and environment. It is not limited to RBAC. Roles can be modeled as one attribute among many, so XACML can express role-based rules, attribute-based rules, or policy-based (PBAC) approaches depending on how policies are authored. It is not accurate to treat XACML as an RBAC-only or an ABAC-only mechanism.
How do XACML's architectural components map to the PDP/PEP/PIP model?
XACML defines a request-response flow that aligns with runtime enforcement components. The Policy Enforcement Point (PEP) intercepts the access attempt and forms a decision request, the Policy Decision Point (PDP) evaluates that request against applicable policies and returns a decision, and Policy Information Points (PIPs) supply additional attribute values needed during evaluation. A Policy Administration Point (PAP) is typically where policies are authored and managed. This is a runtime enforcement concern and is distinct from IGA lifecycle activities such as provisioning or access certification.
What decisions can an XACML PDP return, and how should a PEP handle them?
A PDP typically returns one of a defined set of decision results, commonly Permit, Deny, Not Applicable, or Indeterminate, and may attach obligations or advice. The PEP is responsible for enforcing the decision and, in most deployments, for fulfilling any obligations before granting access. Because a Not Applicable or Indeterminate result is not an explicit Permit, PEPs are generally configured to default to denying access in those cases, though exact handling depends on the deployment's configuration and combining algorithms.
How are conflicts between multiple applicable policies resolved in XACML?
XACML uses combining algorithms to resolve situations where more than one rule or policy applies to a request. These algorithms determine how individual results are combined into a single decision, for example favoring a Deny over a Permit or taking the first applicable result. The specific algorithms available and their exact semantics depend on the XACML version and profile in use, so implementers should confirm behavior against the standard version and the engine they deploy rather than assuming a universal default.
How does XACML obtain the attributes it needs to evaluate a request?
Attributes referenced in a policy can be included in the decision request by the PEP, or they can be retrieved during evaluation from Policy Information Points (PIPs), which may draw from directories, databases, or other attribute sources. The completeness and freshness of these attributes directly affect decision accuracy, so implementations typically need to plan attribute sourcing, caching, and latency carefully. How attributes are resolved and whether missing attributes yield Indeterminate results depends on the deployment and policy design.

Common misconceptions

XACML authenticates users as part of making an access decision.
XACML addresses authorization, not authentication. It determines what an already-identified and authenticated subject may do; establishing who the subject is happens in separate identification and authentication steps outside XACML's scope.
XACML is a competing alternative to RBAC and always superior to it.
XACML is an ABAC-oriented policy language and is not universally superior. It can express role-based logic as a special case, but no access control model is best in every context; the appropriate choice depends on requirements and deployment complexity.
XACML is only a policy file format.
XACML also defines a reference architecture of runtime enforcement components (PEP, PDP, PIP) and administration (PAP), plus a request/response context. It couples a policy language with a decision and enforcement model, though actual behavior varies by implementation and profile.

Best practices

Keep the PEP and PDP responsibilities clearly separated: the PEP should only intercept requests and enforce returned decisions, while the PDP evaluates policy, so that enforcement logic is not embedded in application code.
Externalize authorization from applications by routing access requests through the PDP, allowing policy changes at the PAP without redeploying protected resources.
Design combining algorithms deliberately (for example deny-overrides where a fail-safe posture is required) so that conflicting rule outcomes resolve predictably.
Ensure PIPs can reliably supply the attributes referenced by policies, and account for missing or unavailable attributes, since these can produce Indeterminate decisions that the PEP must handle safely.
Handle obligations and advice explicitly in the PEP, confirming that required obligations are fulfilled before granting access rather than treating them as optional.
Manage policy authoring and versioning through the PAP as a governed administrative process, keeping it distinct from runtime decision-making and validating policies before they reach the PDP.
Promotional banner for the Pentest Readiness checklist download