eXtensible Access Control Markup Language (XACML) Specification

eXtensible Access Control Markup Language (XACML) Specification

eXtensible Access Control Markup Language is an XML Schema for representing authorization and entitlement policies. The XACML 1.0 specification was ratified as an OASIS Open Standard by the OASIS eXtensible Access Control Markup Language Technical Committee in February 2003. Version 1.1 was released in August 2003.

XACML represents the rules that specify the who, what, when, and how of information access. Access control, which is often called rights management , determines who can look at something, what they can do with it, the type of device they can look at it on, and so on.

A set of access control issues has created the need for XACML. First, computing systems are extremely general. Computing platforms have been made as broad and general as possible for the widest possible set of applications that can be run on those platforms. These computing systems also have the broadest possible set of privileges for accessing data and applications, so they can be used in the widest possible set of applications, including those with very permissive (that is, no) security policies.

Second, access control policy enforcement is handled at many different points. In cases of reasonably strict security policy, systems are access controlled at the point of deployment. Enterprise security policy has many elements and points of enforcement, including HR, Finance, Legal, and others.

The third condition that sets up the need for XACML is the plethora of different access control enforcement mechanisms. Each point of enforcement is typically managed independently to make sure the policy is implemented accurately. This makes it prohibitively expensive to modify security policy. It is impossible to obtain a consolidated view of the overall security situation in an enterprise. Despite this fact, pressures increase to demonstrate and prove best practices when protecting information assets.

On top of these three conditions come the machine-to-machine interactions of Web services, which dramatically exacerbate these issues. Combined, these conditions create the need for a common language for expressing information system security policy.

The target of an XACML specification can be any object that is referenced using XML; this gives XACML very fine-grained control. XACML has three top-level policy elements: Policy, PolicySet, and Rule.

The XACML Data Model

At the root of XACML is a concern with access policies ”what XACML refers to as a Policy or a PolicySet. When XACML refers to "policy," it specifically means authorization policy. Each XACML policy document contains exactly one Policy or PolicySet root XML tag. A Policy represents a single access-control policy, expressed through a set of Rules. A Policy is intended to form the basis of an authorization decision. A PolicySet contains a set of Policy or other PolicySet elements and a specified procedure for combining the results of their evaluation. This is the standard means for combining separate policies into a single combined policy. A Rule contains a Boolean expression that can be evaluated in isolation as the basic unit of management; it can be reused in multiple policies.

A few more critical terms used in XACML need to be understood as well. A Target defines a set of resources, subjects, and actions to which a Rule is intended to apply. It is the set of decision requests that a Rule, Policy, or PolicySet is intended to evaluate. An Obligation is an operation specified in a Policy or PolicySet that should be performed in conjunction with the enforcement of an authorization decision. A Condition is an expression that evaluates to True or False or Indeterminate. The Effect is the intended consequence of a satisfied Rule ”either Permit or Deny.

Figure 9.9 shows these XACML concepts.

XACML Operation

XACML defines a very granular set of " layers " to

1. Create policy.
   
   

2. Collect the data required for policy evaluation.
   
   

3. Evaluate policy.
   
   

4. Enforce policy.
   
   

This much granularity enables interoperability for a wide variety of access control approaches. It is an architecture that maximizes flexibility.

Because a generic Policy or PolicySet may contain multiple policies or Rules, each of which may evaluate to different access control decisions, XACML needs some way of reconciling the decisions each makes. In XACML, this is done through a collection of Combining Algorithms . Each algorithm represents a different way of combining multiple decisions into a single decision to build up increasingly complex policies. XACML utilizes Policy Combining Algorithms (used by PolicySet) and Rule Combining Algorithms (used by Policy). The set of Combining Algorithms takes the form of deny-overrides, permit- overrides , first-applicable, and only-one- applicable . These are just a few examples, but an arbitrary set can be created from basic primitives.

<Policy PolicyId="SamplePolicy"

        RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:

          rule-combining-algorithm:first-applicable">



  <!-- This Policy only applies to requests on the SampleServer -->

  <Target>

    <Subjects>

      <AnySubject/>

    </Subjects>

    <Resources>

      <ResourceMatch MatchId="urn:oasis:names:tc:xacml:1.0:

         function:string-equal">

        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

           SampleServer</AttributeValue>

        <ResourceAttributeDesignator DataType="http://www.w3.org/2001/

           XMLSchema#string"

                                     AttributeId="urn:oasis:names:tc:xacml:

                                       1.0:resource:resource-id"/>

      </ResourceMatch>

    </Resources>

    <Actions>

      <AnyAction/>

    </Actions>

  </Target>



  <!-- Rule to see if we should allow the Subject to login -->

  <Rule RuleId="LoginRule" Effect="Permit">



    <!-- Only use this Rule if the action is login -->

    <Target>

      <Subjects>

        <AnySubject/>

      </Subjects>

      <Resources>

        <AnyResource/>

      </Resources>

      <Actions>

        <ActionMatch MatchId="urn:oasis:names:tc:xacml:1.0:

           function:string-equal">

          <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">

            login</AttributeValue>

          <ActionAttributeDesignator DataType="http://www.w3.org/2001/

             XMLSchema#string"

                                     AttributeId="ServerAction"/>

        </ActionMatch>

      </Actions>

    </Target>



    <!-- Only allow logins from 9am to 5pm -->

    <Condition FunctionId="urn:oasis:names:tc:xacml:1.0:function:and">

      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:

        function:time-greater-than-or-equal"

        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:function:

           time-one-and-only">

          <EnvironmentAttributeSelector DataType="http://www.w3.org/2001/

             XMLSchema#time"

                                        AttributeId="urn:oasis:names:tc:

                                        xacml:1.0:environment:current-time"/>

        </Apply>

        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">

           09:00:00</AttributeValue>

      </Apply>

      <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:

        function:time-less-than-or-equal"

        <Apply FunctionId="urn:oasis:names:tc:xacml:1.0:

          function:time-one-and-only">

          <EnvironmentAttributeSelector DataType="http://www.w3.org/2001/

             XMLSchema#time"

                                        AttributeId="urn:oasis:names:tc:

                                        xacml:1.0:environment:current-time"/>

        </Apply>

        <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#time">

         17:00:00</AttributeValue>

      </Apply>

    </Condition>



  </Rule>



  <!-- We could include other Rules for different actions here -->



  <!-- A final, "fall-through" Rule that always Denies -->

  <Rule RuleId="FinalRule" Effect="Deny"/>



</Policy>