Historically application software stacks have defined their own access control languages and environments. These have tended to be proprietary and specifically tailored to the particular application. For example, even in the thoroughly standardised application domain of LDAP directory servers there is no common access control language. Standardisation brings many benefits including the interoperability of systems, the creation of a market for third party tool support and the portability of IT staff skills.

An access control policy simply states "who can do what to what". The who is a subject, the what is an action, and the other what is a resource. In real world physical terms the subject could be a person, the action could be the act of opening, and the resource could be a door. In this case the access control policy could be managed with a lock on the door. The person has to be in possession of the key to open the door. In our virtual world the subject could be a user or a process; the action could be a read, a write, a creation, a modification, a deletion; and the resource could be a file, a database record, or an API method.

Let"s solidify those definitions by looking at an example of an access control rule as written in the XACML Policy schema.

<Rule
      RuleId=""
      Effect="Permit">
    <Description>
        John can open the door.
    </Description>
    <Target>
        <Subjects>
            <Subject>
                <SubjectMatch
                      MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                    <AttributeValue 
                 DataType="http://www.w3.org/2001/XMLSchema#string">John</AttributeValue>
                    <SubjectAttributeDesignator
                          AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                          DataType="http://www.w3.org/2001/XMLSchema#string"/>
                </SubjectMatch>
            </Subject>
        </Subjects>
        <Resources>
            <Resource>
                <ResourceMatch
                      MatchId="urn:oasis:names:tc:xacml:1.0:function:anyURI-equal">
                    <AttributeValue
                 DataType="http://www.w3.org/2001/XMLSchema#anyURI">door</AttributeValue>
                    <ResourceAttributeDesignator
                          AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
                          DataType="http://www.w3.org/2001/XMLSchema#anyURI"/>
                </ResourceMatch>
            </Resource>
        </Resources>
        <Actions>
            <Action>
                <ActionMatch
                      MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
                    <AttributeValue 
                 DataType="http://www.w3.org/2001/XMLSchema#string">open</AttributeValue>
                    <ActionAttributeDesignator
                          AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
                          DataType="http://www.w3.org/2001/XMLSchema#string"/>
                </ActionMatch>
            </Action>
        </Actions>
    </Target>
</Rule>

	   

The rule says "Permit John to open the door." There is a lot of boilerplate XML here, but essentially the rule permits a specific subject, to perform a specific action against a specific resource.

In general a rule can have the effect of either permitting or denying access. In this case the Effect attribute of the Rule element denotes the rule to be a Permit rule. The rule is constrained to the specific subject, resource, and action by the contents of the Subjects, Resources and Actions elements. Attribute values of the identity, resource, and action are combined using functions and operators to produce a matching expression that returns a Boolean value. For example, the action matching expression above compares the action-id attribute with the literal string "open".

<ActionMatch
     MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
     <AttributeValue 
         DataType="http://www.w3.org/2001/XMLSchema#string">open</AttributeValue>
     <ActionAttributeDesignator
         AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
         DataType="http://www.w3.org/2001/XMLSchema#string"/>
</ActionMatch>

	   

The XACML Policy language supports a rich set of data types and functions.

The data types supported are the basic types defined by XML Schema with the addition of data types for email addresses and directory distinguished names: String, Boolean, Integer, Double, Time, Date, DateTime, DayTimeDuration, YearMonthDuration, AnyURI, HexBinary, Base64Binary, RFC822Name, and X500Name.

There are too many functions to list, but they include the simple mathematical operators for all data types, and methods for manipulating sets and bags of values.

An access control policy makes little sense outside of an environment within which subjects are seeking to perform actions against resources. Therefore the XACML specification defines a processing environment and provides terminology for its various components.

The component that processes the policy is called the Policy Decision point, or PDP. The PDP accepts access control requests, processes them against the policy and returns an access control response.

The request and response are also defined as XML, but within an implementation they might never actually exist as documents. Similarly to a policy the request identifies a subject, resource and action. But, the expressions in the request may only contain literal attribute values, and must provide values for the well-known attributes for the subject, resource and action ids.

<?xml version="1.0" encoding="UTF-8"?>
<Request
      xmlns="urn:oasis:names:tc:xacml:1.0:context"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
        cs-xacml-schema-context-01.xsd">
    <Subject>
        <Attribute
              AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
              DataType="http://www.w3.org/2001/XMLSchema#string">
            <AttributeValue>John</AttributeValue>
        </Attribute>
    </Subject>
    <Resource>
        <Attribute
              AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
              DataType="http://www.w3.org/2001/XMLSchema#anyURI">
            <AttributeValue>Door</AttributeValue>
        </Attribute>
    </Resource>
    <Action>
        <Attribute
              AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
              DataType="http://www.w3.org/2001/XMLSchema#string">
            <AttributeValue>open</AttributeValue>
        </Attribute>
    </Action>
</Request>

	   

What generates the request and consumes the response? The Policy Enforcement Point, or PEP.

The PDP must trust the PEP as it is responsible for authenticating the identity of the subject and for enforcing the result of processing the request against the policy. The PEP is usually embedded within an application. An example PEP would be a plugin for a web server that controlled access to web pages.

There are many ways that the PEP could authenticate the acting identity and it is dependent upon the implementation what that might be. In the web server example that could be a simple username or password or something more sophisticated like certificate based client authentication.

The response encapsulates the result of processing the request against the access control policy. The decision can be that of Permit, Deny, NotApplicable, or Indeterminate.

<?xml version="1.0" encoding="UTF-8"?>
<Response
      xmlns="urn:oasis:names:tc:xacml:1.0:context"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="urn:oasis:names:tc:xacml:1.0:context
        cs-xacml-schema-context-01.xsd">
    <Result>
        <Decision>Permit</Decision>
        <Status>
            <StatusCode
                  Value="urn:oasis:names:tc:xacml:1.0:status:ok"/>
        </Status>
    </Result>
</Response>
	   
	   

The PDP and PEP components could reside within the same process, but there are benefits to be derived from their separation. A PDP packaged as a network service, called a policy server, allows multiple different applications, with embedded PEPs, to share the same Policy.

The benefits to application developers are that they no longer need to design and implement their own access control language and processor, they only need to implement a PEP. This reduces the cost of application development and ensures that applications have high quality, secure, expressive access control components.

The benefits to an enterprise using a policy server within its intranet is that its IT security officer can author an access control policy with confidence that it can be faithfully implemented with fewer errors. The IT staff who actually implement the policy will have fewer applications to administer and will have access to third party tools for manipulating, testing and deploying policies.

Within an internet or extranet environment the benefits to an enterprise are that the fine grained expressiveness of the language and the lower cost of making changes allows the business managers to be flexible about opening up information and services to their customers, suppliers and partners.

A policy written only against the attribute values provided within a request would not be very flexible. The policy would degenerate into an exhaustive list of subjects, resources, and actions. We would prefer our policies to be written with a higher level of expressiveness. With this in mind the XACML processing environment defines a Policy Information Point, or PIP, from which the PDP can request additional attribute values. Attribute values can be requested for the subject or the resource.

It is implementation dependent how the PDP talks to the PIP, and how the PDP maps the attributes provided in the request onto attribute value requests to the PIP. Within a heterogeneous network environment a Policy Server implementation would have to include PIP connectors for common subject and resource attribute services. Subject attributes are typically stored within servers that are accessed via network protocols such as LDAP, RADIUS, NIS, NT Domain, etc. Resource attribute services might be the file system, or a relational database system.

One solution to the problem of many protocols is to make the network services homogeneous by having them all talk the same protocol. An OASIS working group has defined the Security Assertion Markup Language for this purpose. SAML is a protocol for expression security assertions, of which there are three kinds: Authentication, Authorization, and Attribute.

In the context of a Policy server implementation a SAML Authorization Assertion can be used as the protocol between the PEP and the PDP, and a SAML Attribute Assertion can be used between the PDP and the PIPs.