In this post we will dive deeper into the architecture of XACML, one of the core aspects of the standard.
XACML stands for eXtensible Access Control Markup Language. It is the OASIS standard for fine-grained authorization management based on the concept of Attribute-based access control (ABAC), where access control decisions are made based on attributes associated with relevant entities, a natural evolution from Role Based Access Control (RBAC).
XACML 1.0 was ratified as an OASIS standard in 2003 and the latest version 3.0 was ratified in January 2013.
The XACML standard covers three major parts – the reference architecture, the policy language and the request-response protocol.
In this post we will take a closer look at the XACML reference architecture.
The standard proposes a reference architecture with commonly accepted names for the various entities involved in the architecture. The nomenclature is not new (SAML uses similar names to describe entities in its ecosystem), nor is the architecture complicated, allowing for easier common base of understanding of the standard.
As per the architecture, when an access request is sent from the subject to perform a specific action on the object, it is intercepted by the Policy Enforcement Point (PEP), which transform the business/application request to a XACML request and sends the XACML request to the Policy Decision Point (PDP), the XACML decision engine that uses the information provided in the XACML request and the rules set in the policy to decide whether the request should be allowed or not.
The PDP uses the Policy Retrieval Point (PRP) to lookup as well as store XACML policies deployed on it. This could be an internal database, an external database or even flat files. It is worth mentioning that PRPs are no longer defined in the latest versions of the standard, though they were in the earlier ones.
The PDP uses the Policy information Point (PIP) to lookup attributes that are referenced in the XACML policy and hence needed to make a decision on the XACML request. In theory PIPs can be any source of attribute information including, but not limited to, LDAP directories, SQL databases or even CSV files. For example, if a particular XACML policy uses the subject attribute of “role” in it, but the XACML request created by the PEP is only able to provide the subject attribute “username”, an LDAP PIP may be useful to lookup the role associated with the username of the subject in question and then use that value to evaluate the request against the XACML policy.
The Policy Administration Point (PAP), as the name suggests, is the architectural entity that is used to manage policies the PDP later evaluates. They, in general, enable the authoring, deployment, change management etc. of the XACML policies.
The architecture stated provides for a logical flow of control. The policy author uses policy authoring tools that form part of the PAP to write XACML policies. The policy administrator then uses the PAP to administer the policies, including deploying them onto necessary PDPs in the access control infrastructure. Policy lifecycle per se is outside the scope of the XACML standard.
The PEP intercepts the business level request to access the resource, produces a XACML request out of it and sends it to the PDP for actual decision making. The PDP, on receiving the XACML request, looks up the XACML policies deployed on it using the PRP and figures out the ones which are pertinent to the specific request. It may, if necessary, query the PIP sources for additional attributes that are needed to evaluate the policies. Armed with the attributes contained in the XACML request, the attributes obtained from the PIPs and attributes (remember XACML is an ABAC system) that are generic to the environment, the PDP decides whether the XACML request can be allowed (Permit response), denied (Deny response), is not applicable since none of the policies deployed on it can be used to evaluate the request (NotApplicable response) or there was some issue with evaluating the response against the policy, for example due to lack of sufficient attributes available to the PDP (Indeterminate response).
The XACML response is then sent by the PDP to the PEP. The PEP parses the response from the PDP and handles each of the four possible response cases using logic that is specific to the application or business logic in question and as such is outside the scope of the XACML standard.
The following video explains the concepts in a step-by-step approach.