What is XACML

eXtensible Access Control Markup Language (XACML) is a vendor-neutral fine-grained access control policy language, architecture, and processing model used to evaluate access requests. The XACML standard was first adopted in 2003, and the current standard, V3.0, has been OASIS’s approved language for Attribute Based Access Control (ABAC) solutions since 2013 and meets EC-US compliance standards.

According to OASIS, XACML is designed: “…to express security policies, as well as the access requests and responses needed for querying the policy system and reaching an authorization decision”. The flexibility of XACML makes it ideal for ABAC, which uses ever changing attributes associated with a user, action, or resource, to determine whether or not to allow access.

This makes XACML flexible and dynamic, allowing for fine-grained authorization with high levels of complexity and abstraction. In XACML, policies are specified separately from where they are enforced, making it easy to immediately update them if a governing policy changes. This also means that unauthorized requests never get to an application or service because they are stopped early in the authorization process.

For all these reasons, XACML is ideal for access control solutions which form a cornerstone of an organization’s cybersecurity deployment, as well as blocking simple unauthorized access, and meeting compliance requirements.

The Fundamentals
of Authorization

Authorization is about determining which users can access which data or

Data-flow model (architectural)

XACML has four key entities. These are:

PAP (Policy Administration Point)

  • Where fine-grained authorization policies are defined and updated.

PDP (Policy Decision Point)

  • The “judge and jury” of XACML. It reviews policies set by the PAP in response to requests from the PEP, reaches a grounded decision to permit or deny access, and instructs the PEP.

PEP (Policy Enforcement Point)

  • The security guard of XACML. It holds access requests at the gate, and only grants or denies them after checking with the PDP and receiving instructions.

PIP (Policy Information Point)

  • A source of attribute values necessary for enforcing policy. If the PDP can’t find all the attributes needed for reaching a decision in the PEP request, it looks for them in the PIP.

The flow between these entities is described (simplified) below:

  1. Policies are authored in the PAP.
  2. The PAP makes these policies available to the PDP.
  3. The PEP stops an access request from a user and formulates a qualified XACML request to the PDP.
  4. The PDP retrieves the policies and evaluates those policies that match the incoming request. In the process of evaluating the rules and policies the PDP may need to retrieve additional and required attribute values from a subsystem i.e. a PIP.
  5. Once a decision is reached, the PDP sends back the effect of the policy decision in a XACML formatted response.

Policy Language

The main building blocks of the XACML language are:


  • A Rule is the most basic element in the XACML language. When the access request is evaluated the Rule will yield an Effect i.e. Permit or Deny. The Rule can include Target, Condition, Obligation and Advice.


  • A Policy contains one or multiple Rules and a Rule combining algorithm. The Rule combining algorithm is used to derive an effect based combining the effects of the included Rules into one decision. The Policy may also include Target, Obligation and Advice.

Policy Set

  • A Policy Set are groups of policies and policy combining algorithms. The Policy Set may also include Target, Obligation and Advice.

Targets and Conditions

  • A Target and a Condition is used to evaluate attribute values. Targets evaluate static combination e.g. action.type == “View” whereas the Condition can compare two attribute values e.g. user.department == document.department.

Obligation and Advice

  • An Obligation and an Advice defines instructions to the PEP (if applicable) that are associated with this Rule e.g. “Log user activity”. Advice is something the PEP acts upon before or after enforcing the decision.

Standardized request/response format between PEP and PDP

The XACML standard defines the format of the request and the response between the PEP and the PDP.

The request includes attributes that represent the user (subject), a resource, an action, and the environment. The response includes the decision i.e. Permit, Deny, Indeterminate (an error occurred, or some required value was missing, so a decision cannot be made) or Not Applicable (the request can’t be answered by this service).

The response can also include an Obligation and/or an Advice. These include instructions to the PEP how to act. The Obligation is something the PEP “must” perform before acting on the decision.

XACML: The Honey
and the Sting

XACML enables use of abstract logic to determine whether or not to grant requested access and enables true fine-grained attribute and policy-based access control. But using XACML can be tricky in several aspects. The “honey” of XACML lies in its standardization, dynamic nature, and flexibility. The “sting” lies in its inheritance, complexity and possible runtime issues.

The Honey

Standardization and Compliance

XACML is an OASIS standard and meets EC-US compliance standards. Standardization ensures enhanced efficiency, with one common language and architecture across developers, enterprises and systems.


XACML is ideal for ABAC. Security policies can be easily updated or reused in multiple enforcement places to accommodate changes in governing policy or user attributes.


XACML is designed to accommodate evolving capabilities, functionality, and growth in an organization or in a system.

The Sting


XACML is an XML based language. XACML policies are verbose and syntactically sensitive. Managing large sets of XACML policies is a highly complex process and must include fool-proof ways of resolving any possible conflicts between Rules and policies. Making even minor changes can be cumbersome and time consuming. To use XACML effectively, you’ll need a skilled XACML programmer.

Limited access pattern

XACML decisions are Boolean i.e. they can only evaluate to Permit and Deny. This makes the traffic between the PEP and the PDP very “chatty”. Every access request for every session needs to be evaluated. Also, various applications, implementations and use-cases expect other responses from the PDP than a Permit or a Deny.

Management and Governance

Due to the above-mentioned complexity, organizations struggle with the adoption and the implementation of XACML at a wider enterprise scale. Without proper visibility and understanding into authorization controls, it is hard for IT stakeholders to engage and take responsibility for business decisions. Authorization management is a practice and competence that needs adoption across single application deployments and here is where the real challenge hides.

Performance Bottlenecks

XACML uses real-time policy evaluation. The PDP must fetch and evaluate policies and go back and forth to the PEP for every access request. This traffic may create bottlenecks, system load issues at runtime, and longer response times. These problems may be alleviated by using a high definition PDP, caching, and other methods.

Dead or Alive

XACML is fading in importance. Despite its ambition, XACML never reached the status of becoming a de-facto industry standard. During the last years evolution of Cloud computing, Microservices architecture and API management XACML has failed to prove its value to the market. New standards and protocols such as OAuth, OpenID Connect, and JWT that are not XML based are gaining more and more ground.

PlainID's PBAC approach
takes the sting out of XACML

PlainID’s Policy Based Access Control (PBAC) solution is the most effective way to leverage all the benefits of XACML and older role- and attribute-based access control solutions (RBAC/ABAC), without the headaches caused by writing and maintaining XACML policies.

The PlainID PBAC solution provides a user-friendly modern PAP that supports the full policy lifecycle including version control and approval workflows. Policies are authored and maintained using a graphical visual editor that allow to construct policies by connecting “policy building blocks” represented in natural language. The PBAC policies are implemented in a graph database that stores and visualizes the relations between identities and resources.

The access decisions are determined dynamically and in real-time, based on the relationships between users and resources plus the contextual characteristics and events that influence the decision at the time access is requested.

The policy engine supports all types of access patterns, not just the Permit/Deny decision. The same policy can support different decisions including; Permit/Deny but also what resources a user can access? Which users can access this resource? Which Rules/Filters apply to this user? This flexibility supports the requirements from both legacy and modern applications.

The PlainID solution also supports advanced analytics that for example includes; a policy test and verification tools that supports impact analysis, SoD controls and policy mining. These more advanced governance capabilities are crucial for enterprise wide deployments in large organizations.

PBAC is truly a “fresh” authorization approach that combines the best of XACML, RBAC and ABAC.

PlainID - Making authorization
"plain and simple"

PlainID’s PBAC solution delivers all the benefits of XACML, RBAC and ABAC, without complex XML coding. It is a dynamic, contextually based and fine-grained authorization solution.

PlainID is the recognized leader of PBAC and has been recognized as one of the fastest growing companies.

Taking the Next Step

Ready to find out more? Click here to schedule a demo with a member of the PlainID team, or check out the PlainID Summary Brief.