Introduction to XACML: Access Control Policies in XML

Introduction

This document discusses the eXtensible Access Control Markup Language (XACML), an XML language for specifying security policies. Security policies are ways to describe who has access to what resources under what conditions. For a large enterprise, there are multiple places at which such security policies must be enforced. It would therefore seem logical to define security policies in a technology neutral way, so that they can be reused. That is exactly the purpose that XACML serves.

Intended Audience

Anyone with an interest in security: developers, administrators, HR people, etc. Basic knowledge of XML is assumed.

XACML Overview

The following figure shows the components (orange rectangles) that make up an XACML-based security system and the data (blue ovals) that those components need as input:

1. A Request comes in at a Policy Enforcement Point (PEP).
2. The PEP forwards the Request to the Context Handler.
3. The Context Handler asks the Policy Information Point (PIP) for Context Attributes.
4. The PIP collects Context Attributes from the Subject (e.g. the role), the Resource (e.g. it's location), and the Environment (e.g. the location from where the Request is made) and returns them to the Context Handler.
5. The Context Handler gets the Resource's content.
6. The Context Handler presents the Request to the Policy Decision Point (PDP), along with the Context Attributes and (optionally) the Resource's content.
7. The PDP makes a decision based on the security policies that the Policy Administration Point (PAP) has previously made available.
8. The PDP returns its decision to the Context Handler, which returns it to the PEP.
9. The PEP either grants or denies access to the Request, based on the PDP's decision
   

There are two main points to take away from this. The first is that the system is made up of components that can be standardized. For instance, the PDP takes well-defined data as input and provides a well-defined interface to the PAP and Context Handler. So organizations don't need to re-invent the wheel by implementing their own PDP, instead they can reuse an existing implementation and hook it up to their implementation of non-standard components, like the PEP.

The second important point is that security policies are specified separately from where they are enforced, which means that we can reuse them in multiple enforcement places. And there is yet another way in which XACML promotes reuse. To see that, we need to take a closer look at how security policies are specified in XACML.

Specifying Access Control: Rules, Policies, and Policy Sets

Rules

A Rule combines a Target, an Effect and a Condition. The Target specifies what the Rule is applicable for: any or all of the requested Action, the Subject requesting the Action, the Resource that the requested Action pertains to, and the Environment within which the Action is to be performed. The Effect of the Rule is to deny or permit the Action. The optional Condition further refines the applicability of the Target.

Here's a simple example of a Rule:

 
  
    Some optional text that explains the purpose of the rule
  
  
    
      
                    "urn:oasis:names:tc:xacml:2.0:function:string-equal">
                        "http://www.w3.org/2001/XMLSchema#string">
            developer
          
          
            role
          
        
      
    
  

This piece of XACML specifies that anybody with the developer role can do anything to any resource. In the example above, we assume the role Attribute to be a single string value, but XACML also supports multi-valued Attributes.

Note that the PIP component needs to be able to extract a value from the Request (see below) that belongs to the Subject attribute named in the SubjectAttributeDesignator element (role in the above example). An alternative way of extracting values from the Request is by providing an XPath expression in the AttributeSelector element.

The PDP component needs to be able to understand the function specified using the MatchId attribute (urn:oasis:names:tc:xacml:2.0:function:string-equal in the example). XACML makes many standard functions available to policy writers, and the specification allows for adding custom ones as well.

A Rule can also contain a Condition that must be satisfied for the Rule to return its Effect. If the Condition returns Indeterminate, the Rule also returns Indeterminate. If the Condition returns False, the Rule returns NotApplicable. If the Condition returns True, the value of the Effect element is returned, which is either Permit or Deny. If the Condition is missing, as in the above example, it is assumed to be True.

Rules can be separately evaluated, but they cannot live on their own: they must be part of a Policy. Rules are the smallest unit of reuse in XACML, while Policies are the smallest unit of evaluation.

Policies

A Policy has a Target, a Rule-Combining Algorithm, some Rules, and some Obligations. We've seen the Target already as part of a Rule. Since a Policy also specifies a Target, a Rule need not specify one. If it doesn't, then it inherits the Target from the Policy. The Rule-Combining Algorithm specifies the procedure by which the results of evaluating the Rules are combined when evaluating the Policy. An Obligation is an operation specified in a Policy that should be performed by the PEP in conjunction with the enforcement of an authorization decision.

Here's the above example Rule wrapped in a Policy:

    "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
  
    Some optional text that explains the purpose of the policy
  
  
    
      
                    "urn:oasis:names:tc:xacml:2.0:function:string-equal">
                        "http://www.w3.org/2001/XMLSchema#string">
            developer
          
          

          
        
      
    
  
  

The RuleCombiningAlgId attribute on the Policy identifies the algorithm that combines Effects from multiple Rules into a single result. The PDP must implement such an algorithm. The Policy may also specify parameters to be used as input for combining algorithms.

The Rule in this Policy example does not specify a Target, but it could. In that case, the Rule would only be evaluated for the Policy if its Target is matched.

Policy Sets

Just as Rules can be reused in Policies, entire Policies can be reused in Policy Sets. A Policy Set contains a Target, a Policy-Combining Algorithm, a set of Policies, and some Obligations. The Policy-Combining Algorithm specifies the procedure by which the results of evaluating the component Policies are combined. Note that a Policy Set can reuse not just Policies, but also entire Policy Sets. This Lego-like structure makes it possible to build complex security policies without duplication.

Here's the above Policy wrapped in a Policy Set:

More Here

Courtesy:https://community.emc.com/docs/DOC-7314