Main | Differences between XACML 1.0 and 2.0 »
January 07, 2005
Differences between XACML versions 1.0 and 2.0
This document outlines the apparent differences between XACML versions 1.0 and 2.0. It is based on Committee Draft 04 of XACML 2.0, dated 6 December 2004, and on the schemas accompanying the XACML 1.0 specification.
Version 2.0 documents:
- http://docs.oasis-open.org/xacml/access_control-xacml-2_0-core-spec-cd-04.pdf
- http://docs.oasis-open.org/xacml/access_control-xacml-2.0-policy-schema-cd-04.xsd
- http://docs.oasis-open.org/xacml/access_control-xacml-2.0-context-schema-cd-04.xsd
Version 1.0 documents:
- http://www.oasis-open.org/committees/download.php/915/cs-xacml-schema-policy-01.xsd
- http://www.oasis-open.org/committees/download.php/919/cs-xacml-schema-context-01.xsd
Changes in the context schema
-
The namespace used in the XACML 2.0 schema is urn:oasis:names:tc:xacml:2.0:context:schema:cd:04, which I assume is specific to Committee Draft 04. The equivalent namespace in XACML 1.0 was urn:oasis:names:tc:xacml:1.0:context.
-
In XACML 2.0, a Request may contain more than one Resource. This looks like a change to be compatible with SAML.
-
While in XACML 1.0 it was not necessary to specify an Environment in a Request, in XACML 2.0 the Environment is mandatory.
-
In XACML 1.0, an Attribute contains exactly one AttributeValue. In XACML 2.0, it can contain more than one. This, again, looks like a SAML compatibility measure.
-
The IssueInstant attribute that appeared optionally on Attribute elements in XACML 1.0 has been phased out in XACML 2.0.
-
The Status element in a Result was mandatory in XACML 1.0 but is optional in XACML 2.0. According to the specification (section 6.10):
If the <Response> element contains <Result> elements whose <Status> elements are all identical, and the <Response> element is contained in a protocol wrapper that can convey status information, then the common status information MAY be placed in the protocol wrapper and this <Status> element MAY be omitted from all <Result> elements.
-
A new element, MissingAttributeDetail, has been added in XACML 2.0.
<xs:element name="MissingAttributeDetail" type="xacml-context:MissingAttributeDetailType"/> <xs:complexType name="MissingAttributeDetailType"> <xs:sequence> <xs:element ref="xacml-context:AttributeValue" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> <xs:attribute name="DataType" type="xs:anyURI" use="required"/> <xs:attribute name="Issuer" type="xs:string" use="optional"/> </xs:complexType>
MissingAttributeDetail is not mentioned anywhere in the schema except in its own definition. However, according to section 6.15 of the spec, one or more MissingAttributeDetail elements can be used inside a StatusDetail (where there is an xs:any) when the PDP returns the status "missing-attribute".
Changes in the policy schema
-
The namespace has changed from urn:oasis:names:tc:xacml:1.0:policy in XACML 1.0 to urn:oasis:names:tc:xacml:2.0:policy:schema:cd:04 in the current draft of XACML 2.0. As with the context schema, I do not expect this new namespace to be final.
-
XACML 2.0 introduces CombinerParameters.
<xs:element name="CombinerParameters" type="xacml:CombinerParametersType"/> <xs:complexType name="CombinerParametersType"> <xs:sequence> <xs:element ref="xacml:CombinerParameter" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:element name="CombinerParameter" type="xacml:CombinerParameterType"/> <xs:complexType name="CombinerParameterType"> <xs:sequence> <xs:element ref="xacml:AttributeValue"/> </xs:sequence> <xs:attribute name="ParameterName" type="xs:string" use="required"/> </xs:complexType>
<xs:element name="RuleCombinerParameters" type="xacml:RuleCombinerParametersType"/> <xs:complexType name="RuleCombinerParametersType"> <xs:complexContent> <xs:extension base="xacml:CombinerParametersType"> <xs:attribute name="RuleIdRef" type="xs:string" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType>
<xs:element name="PolicyCombinerParameters" type="xacml:PolicyCombinerParametersType"/> <xs:complexType name="PolicyCombinerParametersType"> <xs:complexContent> <xs:extension base="xacml:CombinerParametersType"> <xs:attribute name="PolicyIdRef" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType>
<xs:element name="PolicySetCombinerParameters" type="xacml:PolicySetCombinerParametersType"/> <xs:complexType name="PolicySetCombinerParametersType"> <xs:complexContent> <xs:extension base="xacml:CombinerParametersType"> <xs:attribute name="PolicySetIdRef" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType>
Any number of CombinerParameters, PolicyCombinerParameters and PolicySetCombinerParameters elements can be added inside a PolicySet, after the Target. CombinerParameters and RuleCombinerParameters elements can appear inside a Policy.
According to the spec, these elements contain parameters for use by combining algorithms. The standard combining algorithms defined in the spec do not use parameters, but their inclusion allows a wider range of third-party algorithms to be defined. Further information can be found in sections 5.24 to 5.28 of the spec.
-
The Policy and PolicySet elements in XACML 2.0 also have a new optional attribute, Version, with default value "1.0". Its type is defined in the schema.
<xs:simpleType name="VersionMatchType"> <xs:restriction base="xs:string"> <xs:pattern value="((\d+|\*)\.)*(\d+|\*|\+)"/> </xs:restriction> </xs:simpleType>
Section 5.20 of the spec says that the attribute contains the version of the policy or policy set (not an XACML version).
-
In XACML 1.0, the PolicySetIdReference and PolicyIdReference elements had type xs:anyURI. In XACML 2.0, their type is xacml:IdReferenceType, which is an xs:anyURI with three optional attributes.
<xs:complexType name="IdReferenceType"> <xs:simpleContent> <xs:extension base="xs:anyURI"> <xs:attribute name="Version" type="xacml:VersionMatchType" use="optional"/> <xs:attribute name="EarliestVersion" type="xacml:VersionMatchType" use="optional"/> <xs:attribute name="LatestVersion" type="xacml:VersionMatchType" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType>
These attributes refer to the version of the policy or policy set, or to a range of versions, which the reference matches. Details can be found in sections 5.18 and 5.19 of the spec.
-
XACML 2.0 allows three new elements inside Policy elements: CombinerParameters, RuleCombinerParameters, and VariableDefinition. All are optional and can be used instead of a Rule. Each element can be used as many times as desired. It is also legal to put a single CombinerParameters before the policy's Target.
CombinerParameters and RuleCombinerParameters are as described above. The definition of VariableDefinition follows:
<xs:element name="VariableDefinition" type="xacml:VariableDefinitionType"/> <xs:complexType name="VariableDefinitionType"> <xs:sequence> <xs:element ref="xacml:Expression"/> </xs:sequence> <xs:attribute name="VariableId" type="xs:string" use="required"/> </xs:complexType>
A VariableDefinition defines a value that can be referenced from within the same policy by a VariableReference. See section 5.31 of the spec.
-
XACML 2.0 defines a new element called VariableReference.
<xs:element name="VariableReference" type="xacml:VariableReferenceType" substitutionGroup="xacml:Expression"/> <xs:complexType name="VariableReferenceType"> <xs:complexContent> <xs:extension base="xacml:ExpressionType"> <xs:attribute name="VariableId" type="xs:string" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType>
This is used to refer to a value by its VariableDefinition, as described in section 5.32 of the spec. A VariableReference must match a VariableDefinition within the same policy.
VariableReference is in the Expression substitution group, so it can be used in the same places as an AttributeValue, Function, etc. (see below)
-
In XACML 1.0, the RuleId attribute on a Rule had to be an xs:anyURI. In XACML 2.0 it is an xs:string.
-
In XAMCL 2.0 there is an EnvironmentMatch element, formed by analogy with SubjectMatch, ResourceMatch and ActionMatch and usable in the same places.
<xs:element name="EnvironmentMatch" type="xacml:EnvironmentMatchType"/> <xs:complexType name="EnvironmentMatchType"> <xs:sequence> <xs:element ref="xacml:AttributeValue"/> <xs:choice> <xs:element ref="xacml:EnvironmentAttributeDesignator"/> <xs:element ref="xacml:AttributeSelector"/> </xs:choice> </xs:sequence> <xs:attribute name="MatchId" type="xs:anyURI" use="required"/> </xs:complexType>
-
In XACML 1.0 Target elements, the Subjects, Resources and Actions elements are all mandatory. In XACML 2.0 they are optional, and there is also an optional, similar Environments element.
<xs:element name="Environments" type="xacml:EnvironmentsType"/> <xs:complexType name="EnvironmentsType"> <xs:sequence> <xs:element ref="xacml:Environment" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
<xs:element name="Environment" type="xacml:EnvironmentType"/> <xs:complexType name="EnvironmentType"> <xs:sequence> <xs:element ref="xacml:EnvironmentMatch" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType>
-
The AnySubject, AnyResource and AnyAction elements from XACML 1.0 have been eliminated in XAMCL 2.0. The same effect is now achieved by missing out, respectively, a Subjects, Resources or Actions element from the Target (see section 5.5 of the spec).
-
In XACML 2.0, the elements Apply, AttributeSelector, AttributeValue, Function, VariableReference, and all FooAttributeDesignator elements are members of a new substitution group called Expression, and are based on an abstract Expression type. However, their content and syntax are unchanged.
-
In XACML 2.0, Condition and Apply are now defined in terms of the Expression substitution group. A Condition contains a single element from the Expression group. An Apply can contain any number of elements from the Expresson group, and also has a required FunctionId attribute. In terms of syntax, the difference from XACML 1.0 is that an Apply has exactly the same syntax, while a Condition lacks the FunctionId attribute and is restricted to having only one element inside.
-
It is legal in XACML 2.0 to have an Obligation with no AttributeAssignment inside. See the spec, section 5.45 and 5.46.
Posted by daniel at January 7, 2005 12:46 PM