A Quick Introduction to XACML

The eXtensible Access Markup Language is a standard for defining Access Control Lists (ACL) and corresponding requests/ responses. ACL is a concept that comes under the umbrella of Authorization. An ACL defines who can access which resource under what conditions. The basis of decision lies in the security policy of an organization. The most common example of ACL is a file system such as NTFS where you can specify separate access rights for a folder/ file against every user/ group.

Traditionally, applications define their own mechanisms for handling requests and responses. The most common practices is to invoke an authorization request as a function call which in turn checks in a database (which has tables like user, role and user_roles, with the actions allowed to a role hard-coded in the application logic).

XACML, like many other standards, might be an overkill for small applications but for enterprise level applications it provides a single way of handling things. Thus, several distinctly developed applications/ components could interact seamlessly with each other.

[If you are a casual surfer who reached here, I think that's all you need to know about XACML. If you are still interested, read on.]

Three important types of XML documents exist in XACML: Policy, Request and Response. A policy is stored in a policy repository (which can be a database). Requests and Responses are dynamic XML documents created when somebody tries to access a protected resource.

The two most important components of XACML are Policy Enforcement Point (PEP) and Policy Decision Point (PDP). A PEP is a component that has the capability of protecting the resource or allowing access to it depending on what the policy says. A hypothetical XACML powered file system is a good example of a PEP as it is responsible for serving the contents of a folder or a file. Another good example is a hypothetical XACML powered web server. A PEP, however, can't take the decision itself.

A PDP, on the other hand, is the component which is responsible for evaluating the request and checking the appropriate policy and giving a verdict in terms of yes and no (or not applicable).



XACML Components @ Work

As you can see, a user interacts with a PEP for accessing a resource. The communication between the user and PEP is unchanged in XACML world (it can be an HTTP request in case of a web server, for example). The PEP forms an XACML request (by taking out user credentials from the request) and sends them to a PDP. The message from PEP to PDP follows XACML Request schema. The PDP in turn picks out the appropriate policy by consulting the policy repository. The Policy itself follows XACML Policy schema. The PDP evaluates the request with respect to the policy and forms an XACML response for PEP. The message from PDP to PEP follows XACML Response schema.

If you are going to use XACML, the chances are that you'll be writing a PEP or a PDP. There are open source implementations for both Java and .NET available on sourceforge. They are from Seth Proctor of Sun Microsystems and Diego Gonzalez of Lagash respectively. Quite interestingly, both of these projects don't have any other contributors. The implementations provide the basic framework for extracting appropriate fields from the request, match with the target policy, evaluate the policy, etc. The best point to learn more will be to read some examples of policy and requests/responses. Finally, you can read the complete specs here.