eXtensible Access Control Markup Language (XACML) what is it and why is it important?

January 7, 2012 by · 1 Comment
Filed under: Architecture, Security 

XACML is a security standard that was created to make the use of security for software easy to configure, extend, and change with minimal impact.  It is a policy based language so that you abstract out the security policies from the source code of the systems, making this less tightly coupled.  Here is a good overview with more details: 

The sad fact is that in development and design of software systems and application security is often an after-thought.  most systems leverage an role-based access control (RBAC)  system which uses permissions and roles to control access.  When or if security policies change things usually require making more roles, and permissions, and management can be difficult.  With RBAC you can be plagued with Role-explosion where you need a role for each person to permission mapping especially in context based security requirements. 

XACML is a standard defined by the OASIS standards association.  XACML is attribute based over role based so that it makes management easier (access based on attributes) but the most important factor is the decoupling of the authorization access from the system so changes are easier and maintenance is also easier.  A side-effect of abstracted authorization is that you can interoperate and centralize security to share it across different systems, even federated security scenarios leverage XACML.

The basic design of a XACML systems has 4 main components a PAP, PEP, PIP and PDP

1 – PAP is the Policy Administration Point This is where you administer the policies changing the security rules, and policies. This is separate from the rest of the system as this is decoupled..

2 – PEP is the Policy Enforcement Point.  The PEP enforces the access so this is the module that authenticates the request for validity, getting identity information and can also constrain data, cache, and gets the request and then also returns the result, usually a simple Yes or No, however in some systems the actual deliverable, the data being secured is returned from the PEP rather than just a yes/no decision.

3 – PIP is the Policy Information Point. PIP is a service that collects information for the policy decision point to use to make a decision, this is to ensure that all the information that is needed is available.  The PIP usually is a front-end to many other backend systems containing the attributes you use for security policies decisions.

4 – PDP is the Policy Decision Point.  This is where the magic happens, using a rules engine or something similar, the decision point makes a decision about the access request, and also can loop back to the PIP for more information as the policies are executed. 


The diagram shows a basic flow for access to security using a XACML based system.

We will go over some of the more advanced scenarios supported and also the benefits such a system provides even if it may seem like overkill.  I think that as systems and information architecture mature this security model will be the future because of the abstraction it allows.