Sunday, June 14, 2009

Anatomy of the XACML Request

Going by an example is the easiest way to explain.

<Request xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os" xmlns:xsi="">
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id" DataType="">
  <Attribute AttributeId="group" DataType="">
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id" DataType="">
  <Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id" DataType="">
Let's started with breaking it down.


Represents the entity making the access request.

Can contain multiple <Attribute> elements.

A given Subject is identified by the attributes contained.

Each <Attribute> has two attributes. AttributeId and the DataType.

AttributeId can be a one of your own or one defined by the XACML specification.

Following are the set of special identifiers defined in XACML related to the Subject.

In our example, for the first Attribute under the Subject we use the special identifier, urn:oasis:names:tc:xacml:1.0:subject:subject-id. For the next Attribute, we use our own - 'group'. This can be anything - mail,givenName,accessList or any custom attribute - which could be identified by the defined XACML policy, where this request will be evaluated against.

The next attribute defined in the <Attribute> element is the DataType. It basically defines the type of data <AttributeValue> element should contain.

Following are set of data types defiend in XACML.
In our case both the Attributes are of type

So, the bottom line is, the <Subject> element defines who wants to access.


This defines, the data,service or system component - which the Subject wants to access.

The <Resource> element contains one or more attributes of the resource to which the subject (or subjects) has requested access. There can be only one <Resource> per decision request.

Once again, a given <Resource> is identified by the <Attribute> child element. In our example, the Subject wants access to the Resource http://localhost:8280/services/echo/echoString.


The <Action> element contains one or more attributes of the action that the subject (or subjects) wishes to take on the resource. There can be only one action per decision request.

Here also, a given <Action> is identified by the <Attribute> child element. In our example, the Subject wants Read access to the resource http://localhost:8280/services/echo/echoString.


A more complex request context may have contained some attributes not associated with the subject, the resource or the action. These would have been placed in an optional <Environment> element following the <Action> element.