What is XACML (Extensible Access Control Markup Language)?
What are XACML use cases?
XACML is used to promote interoperability and common terminology for access control implementations, where access attributes associated with a user are used to decide whether a user may have access to a specific resource.
XACML simply provides the following:
- an access control architecture that contains a policy decision point and a policy enforcement point; and
- authorization policies that can denote a variety of access control policies.
What is the history of XACML?
Ratified by the Organization for the Advancement of Structured Information Standards (OASIS) in February 2003, XACML 1.0 was developed to standardize access control through XML. For example, with XACML, a worker can access several affiliated websites with a single login.
The XACML specifications were developed through a collaborative effort of OASIS members including IBM, Sun Microsystems and Entrust.
The latest version is XACML 3.0, released by OASIS in January 2013.
The following are terms used with XACML policies.
Policy Administration Point (PAP). PAP is the point which manages access authorization policies.
Policy Decision Point (PDP). This is the point where access requests are evaluated against authorization policies before issuing access decisions.
Policy Enforcement Point (PEP). The PEP is where user access requests are intercepted to make a decision request to the PDP.
The typical flow of an XACML request is as follows:
- A user sends a request which is intercepted at the PEP.
- The PEP converts the request into an XACML request.
- The PEP transmits the request to the PDP.
- The PDP evaluates the authorization request against the access policies it has configured. Those policies are managed at thePAP. If necessary, attribute values from Policy Information Points can also be retrieved.
- Finally, at the PDP a decision is made, which will either be "Permit," "Deny," "NotApplicable," or "Indeterminate," and returned in boolean to the PEP.
XACML policy elements
The following is a high-level overview of the various elements that make up an XACML policy.
The structure of XACML is split into the following three sections:
- Rule (ruleID)
All policy sets, requests and sets of rules use resources, subjects, environments and actions. These are typically denoted in XACML syntax as "attributeID."
- The subject (access-subject) is the entity requesting access.
- The resource can be a service, data or a system component.
- An action (action-ID) refers to the type of access requested.
- The environment refers to an element that can provide additional information if necessary.
XACML language defines a target, which is the conditions for a resource, subject, resource or action that are necessary to meet access requirements and provide an authorization decision.
Since its creation, the XACML Technical Committee has created new profiles to facilitate developer integration, including the following:
- The REST profile of XACML;
- The JSON profile of XACML; and
- The ALFA profile of XACML.
With these profiles, integrating authorization into applications has been made much easier for software development teams.
XACML and related standards
There are a few additional policy languages that have similar functions to XACML.
XACML vs. Open Policy Agent
Similar to XACML, Open Policy Agent (OPA) provides a policy decision point, policy language (Rego) and an externalized authorization. This standard focuses on infrastructure authorization as opposed to API-centric authorization, which XACML covers.
XACML vs. SAML
XACML was designed to work in conjunction with Security Assertion Markup Language (SAML), another OASIS standard. SAML defines a means of sharing authentication information, such as user passwords and security clearance, between security systems.
A rules engine -- a program that examines established rules and suggests behaviors that comply with them -- with policies expressed in XACML can compare such information with established criteria to ascertain user rights.