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?
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.