How does XACML 3.0 differ from XACML 2.0?

Question

I'm considering migrating my client application from using a XACML 2.0 authorization service to using a newer XACML 3.0 service.

What changes or issues will I run into in migrating my client app from making XACML 2.0 requests to making XACML 3.0 requests?

Answer 1

The biggest difference between XACML 2.0 and XACML 3.0 for your client app is that the structure of the attributes in the authz request have changed significantly in XACML 3.0.

In XACML 2.0, attributes were organized into subject, resource, environment, or action categories using XML element tags:

<?xml version="1.0" encoding="UTF-8"?>
<Request  xmlns="urn:oasis:names:tc:xacml:2.0:context:schema:os"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="urn:oasis:names:tc:xacml:2.0:context:schema:os  access_control-xacml-2.0-context-schema-os.xsd">
        <Subject>
            <Attribute
                  AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
                  DataType="http://www.w3.org/2001/XMLSchema#string">
                <AttributeValue>Julius Hibbert</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>http://medico.com/record/patient/BartSimpson</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>read</AttributeValue>
            </Attribute>
        </Action>
        <Environment/>
</Request>

In XACML 3.0, these categories are indicated using XML attributes instead of XML element tags:

<?xml version="1.0" encoding="utf-8"?>
<Request xsi:schemaLocation="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17 http://docs.oasis-open.org/xacml/3.0/xacml-core-v3-schema-wd-17.xsd" ReturnPolicyIdList="false" CombinedDecision="false" xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject">
    <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">Julius Hibbert</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource">
    <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#anyURI">http://medico.com/record/patient/BartSimpson</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action">
    <Attribute IncludeInResult="false" AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id">
      <AttributeValue DataType="http://www.w3.org/2001/XMLSchema#string">read</AttributeValue>
    </Attribute>
  </Attributes>
  <Attributes Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" />
</Request>

The <Subject> element in XACML 2.0 becomes <Attributes Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"> in XACML 3.0, for example. Ditto for the resource, environment, and action categories.

This structural change simplifies the processing model for handling requests and makes it easy to extend the model with custom application-specific or domain-specific categories without running afoul of schema validation.

There are new data types and functions defined in XACML 3.0 for use in policy definitions. The AnyURI data type is now distinct from the string datatype. Several of the 2.0 combining algorithms have been deprecated in favor of new 3.0 equivalents that define more precisely how indeterminate states propagate up through the policy decision tree. The old combining algorithms are still included as "legacy" artifacts.

XACML 2.0 requests and policies can be mechanically converted to XACML 3.0 format with no loss of information. Converting a 3.0 response back to 2.0 format is doable if you stick to simple permit/deny responses.

Answer 2

Please check the OASIS XACML TC wiki for an official list of differences:

"Differences between XACML 2.0 and XACML 3.0"

In a nutshell...

The key difference between XACML 2.0 and XACML 3.0 is in new features such as

• obligation expressions: you can have dynamic parts to your obligation statements
• the introduction of advice which effectively is generalizing obligations to a broader scope
• the introduction of the XACML v3.0 Administration and Delegation Profile Version 1.0. To date Axiomatics and ViewDS (http://www.viewDs.com) are the only complete XACML 3.0 implementations that includes delegation. It is a key feature for cloud and federated deployments. The delegation model is the result of 5+ years of R&D at the Swedish Institute of Computer Science (SICS).

This information is summarized on the XACML TC wiki page at OASIS. The TC is backed by such leading organization as Oracle, IBM, and Axiomatics. The editor of the XACML 3.0 specification is Axiomatics's CTO, Erik Rissanen.

Also, Kuppinger Cole delivered a webinar on the topic: "Policy Based Access Control with XACML 3.0".

Lastly, I summarized the new features on "Enhancements and new features in #XACML 3.0".