XACML – A standard that I wish I had known about earlier
In the past, I have had to provide some sort of security and access control mechanisms for various sorts of resources in various projects. In all those cases, I had created security components that handled the respective requirements adequately but were slightly different in each case. I knew that they all shared the same core idea of access control based on authentication and authorization but just didn’t get to the point of building a generic framework that handle all those cases with little customization. But I got curious and scoured the web for previous work on the subject which is when I came across XACML. XACML which stands for eXtensible Access Control Markup Language provides a policy language which allows administrators to define the access control requirements for their users to application resources. XACML was approved and became an OASIS standard in February 2003. It is an initiative to develop a standard for access control and authorization systems. The XACML 2.0 specification document can be found here.
A typical access control and authorization scenario includes three main entities — a subject, a resource, and an action — and their attributes. A subject creates and initiates a request to perform an action on a resource. For example, in the access request, “Allow the District Manager to create features in the District Layer” the subject is the “District Manager” the resource is the “District Layer” and the action is “create features”. Proprietary access control systems store information about these entities in their own schema in the repository which are typically referred to as the “Access Control Lists (ACLs)”. XACML serves to standardize the repository schema and can help with sharing access control information across diverse systems running on different platforms.
The main components that comprise a system implementing XACML is shown below.
PEP (Policy Enforcement Point) – This component receives the request from the subject(s) for permission to perform an action on a resource. It forwards the request along to the PDP (Policy Decision Point) and passes back the response from the PDP.
PDP (Policy Decision Point) – This components studies the request and evaluates all the policies that are applicable to the action and resource in the request. The result of the evaluation is sent back as the response to the request.
PAP (Policy Access Point) – This component makes available all the policies and rules that are applicable in context to the PDP.
PIP (Policy Information Point) – This component retrieves information about the subject, the resource, or the environment
XACML sub-components –
- Target – The target helps in determining whether the policy is relevant for the request.
- Rules – Multiple rules can be associated to a policy. Each rule is composed of a condition, an effect, and a target.
- Condition – are statements about attributes that upon evaluation return either
- Effect – is the intended consequence of the satisfied rule. It can either take the value
- Target – helps in determining whether or not a rule is relevant for a request.
- Rule-combining algorithm – are responsible for resolving such conflicts that can arise due to different results from different rules that are being combined to arrive at one outcome per policy per request.
- Obligations – provides much finer-level access control than mere permit and deny decisions. Obligations are the actions that must be performed by the PEP in conjunction with the enforcement of an authorization decision.
If you are really excited about using the standard and are chomping at the bits to make use of it in your projects, but don’t really want to do all the work to convert the specification into a reusable .NET library. Then you are in lucky, a .NET implementation for XACML is already available in the form of XACML.NET and can be downloaded from here.