XML and Security: 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:

 

 

xacml-overview.png

 

 

  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:

 

<Rule RuleId="rul-0001" Effect="Permit">
  <Description>
    Some optional text that explains the purpose of the rule
  </Description>
  <Target>
    <Subjects>
      <Subject>
        <SubjectMatch MatchId=
            "urn:oasis:names:tc:xacml:2.0:function:string-equal">
          <AttributeValue DataType=
              "http://www.w3.org/2001/XMLSchema#string">
            developer
          </AttributeValue>
          <SubjectAttributeDesignator>
            role
          </SubjectAttributeDesignator>
        </SubjectMatch>
      </Subject>
    </Subjects>
  </Target>
</Rule>

 

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:

 

<Policy PolicyId="pol-0001" RuleCombiningAlgId=
    "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
  <Description>
    Some optional text that explains the purpose of the policy
  </Description>
  <Target>
    <Subjects>
      <Subject>
        <SubjectMatch MatchId=
            "urn:oasis:names:tc:xacml:2.0:function:string-equal">
          <AttributeValue DataType=
              "http://www.w3.org/2001/XMLSchema#string">
            developer
          </AttributeValue>
          <SubjectAttributeDesignator>
            role
          </SubjectAttributeDesignator>
        </SubjectMatch>
      </Subject>
    </Subjects>
  </Target>
  <Rule RuleId="rul-0001" Effect="Permit"/>
</Policy>

 

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:

 

<PolicySet PolicySetId="pls-0001" PolicyCombiningAlgId=
    "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">
  <Description>
    Some optional text that explains the purpose of the policy set
  </Description>
  <Target>
    <Subjects>
      <Subject>
        <SubjectMatch MatchId=
              "urn:oasis:names:tc:xacml:2.0:function:string-equal">
          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">
            developer
          </AttributeValue>
          <SubjectAttributeDesignator>
            role
          </SubjectAttributeDesignator>
        </SubjectMatch>
      </Subject>
    </Subjects>
  </Target>
  <PolicyIdReference>
    pol-0001
  </PolicyIdReference>
  <Policy PolicyId="pol-0001" RuleCombiningAlgId=
      "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:deny-overrides">
    <Target/>
    <Rule RuleId="rul-0001" Effect="Permit"/>
  </Policy>
</PolicySet>

 

Enforcing Access Control: Requests and Reponses

Request

We've had looked a quick look at how security policies are specified. Now let's see how they are used. As stated above, the PDP will match the Target of the Policy Sets, Policies, and Rules against the Request to see whether they are applicable.

 

The Request consists of attributes for the Subject(s), Resource, Action, and Environment. For XML Resources, the Resource content can even be included, so that, for example, a Rule could deny access to Resources that contain credit card information, but permit access to Resources that don't. Attributes are named, so that Rules can refer to them, and strongly typed, so that the PDP can do proper comparisons. The Environment Attributes allow different access decisions to be made, for example depending on whether the Subject is in a public place or within the secure confines of his office.

 

Here's an example of a Request:

 

<Request>
  <Subject>
    <Attribute AttributeId="role"
        DataType="http://www.w3.org/2001/XMLSchema#string">
      developer
    </Attribute>
  </Subject>
  <Resource>
    <ResourceContent>
      <!--
        In case the Resource is an XML document, it can be inlined
        here, so that Rules can depend on the contents.
      -->
      <example/>
    </ResourceContent>
    <Attribute DataType="http://www.w3.org/2001/XMLSchema#string"
        AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
      /some/example.xml
    </Attribute>
  </Resource>
  <Action>
    <Attribute DataType="http://www.w3.org/2001/XMLSchema#string"
        AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
      retrieve.contents
    </Attribute>
  </Action>
  <Environment>
    <Attribute DataType="http://www.w3.org/2001/XMLSchema#dateTime"
        AttributeId="urn:oasis:names:tc:xacml:1.0:environment:current-dateTime">
      2010-06-14T11:12:03Z
    </Attribute>
  </Environment>
</Request>

 

In this example Request, the Subject has an Attribute named role, that our example Rule refers to using the SubjectAttributeDesignator element. There may be several Resources listed in the Request, in which case multiple access decisions are needed, one per Resource.

 

Response

When the PDP has reached a verdict on whether the Subject may perform the Action on the Resource in the given Environment, it creates a Response object. The Context Handler returns the Response to the PEP, which enforces the decision.

 

Here's an example of a Response:

 

<Response>
  <Result ResourceId="/some/example.xml">
    <Decision>Permit</Decision>
  </Result>
</Response>

 

When the Request contains multiple Resources, the Reponse must contain multiple Results, one per Resource. In case an error is encountered while evaluating the Request, the Result can contain a Status element that indicates what went wrong. The Result may also include Obligations that the PEP must fulfill. One example would be to filter out credit card information before returning the Resource content to the Subject. Another would be to write an audit record. The PEP must either honor all of these Obligations (possibly by calling upon an external Obligations Service), or treat the decision as denied.

 

Summary

This document briefly introduced XACML, a standard for specifying and evaluating security policies in XML. XACML is a technology neutral language that makes reuse of security policies practical and stimulates the creation of standard, reusable components handling such policies. XACML is able to specify security at a granular level suitable for large enterprises and contains powerful constructs for access control checking. Yet it is not so complex as to prevent use in less demanding environments.

 

More to Explore

Real world examples of XACML security policies

Implementing an XACML PEP in Java

Wikipedia lists several XACML implementations. One is an open source implementation from Sun.

 

XACML

Related XML and Security Standards