MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Draft response to SSTC on XACML Attribute definition
At the SAML F2F, I was asked why XACML had chosen to use a
different Attribute definition from SAML. The XACML TC
participants present at the SAML F2F were not able to respond
off-the-cuff, so here is a draft response. Does anyone have more
information, history, opinion, correction, etc?
-Anne
First of all, here are the two schema definitions:
SAML 1.1:
<element name="AttributeDesignator" type="saml:AttributeDesignatorType"/>
<complexType name="AttributeDesignatorType">
<attribute name="AttributeName" type="string" use="required"/>
<attribute name="AttributeNamespace" type="anyURI" use="required"/>
</complexType>
<element name="Attribute" type="saml:AttributeType"/>
<complexType name="AttributeType">
<complexContent>
<extension base="saml:AttributeDesignatorType">
<sequence>
<element ref="saml:AttributeValue" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="AttributeValue" type="anyType"/>
XACML 1.1:
<xs:element name="Attribute" type="xacml-context:AttributeType"/>
<xs:complexType name="AttributeType">
<xs:sequence>
<xs:element ref="xacml-context:AttributeValue"/>
</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:attribute name="IssueInstant" type="xs:dateTime" use="optional"/>
</xs:complexType>
<!-- -->
<xs:element name="AttributeValue" type="xacml-context:AttributeValueType"/>
<xs:complexType name="AttributeValueType" mixed="true">
<xs:sequence>
<xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
The XACML TC started out with the SAML Attribute schema
definition. We diverged as we found difficulties in using the
SAML Attribute schema in policies.
1. XACML AttributeId vs. SAML AttributeName plus AttributeNamespace
In policies, using the SAML definition requires two predicates
to match a single Attribute, e.g. AttributeName="X" AND
AttributeNamespace="Y". We could not find instances where a
policy writer would want to reference "an Attribute from any
AttributeNamespace with the AttributeName X", or "an Attribute
with any AttributeName from AttributeNamespace Y".
Since a URI can be composite, containing a prefix that
indicates the namespace and a suffix that indicates the name,
and since a single predicate can then be used to select the
Attribute, the XACML TC changed the schema to use a single
AttributeID URI. This also is consistent with the naming and
retrieval of Attributes in LDAP.
For example, rather than defining
AttributeNamespace="permisRole" and AttributeName="manager",
XACML would have you define something like
AttributeId="http://www.permis.org/2002/names/roles#manager";
or AttributeId="urn:permis:names:role:manager"
2. Explicit XACML DataType
SAML depends on each AttributeValue having a schema, such that
the schema instance contains tags identifying the type of the
Attribute.
XACML wanted to define a set of standard functions that could
be used with most AttributeValues. By defining a set of
standard DataTypes, with associated semantics and functions
for manipulating those types, most XACML policies can be
defined without recourse to additional schemas, and strict
type checking for the functions can be performed.
Note that is it possible in XACML to define the type of an
AttributeValue by using a schema, since the set of DataTypes
is extensible. A policy writer can set
DataType="urn:myAttributeSchema:attrX", and have the
AttributeValue then be an instance of this schema element.
The policy writer will not be able to use standard functions
with such an Attribute however.
3. SAML sequence of AttributeValue vs XACML AttributeValue that
may contain a sequence
In SAML, an Attribute may contain one or more AttributeValue
elements. In XACML, an Attribute contains a single
AttributeValue element, although that element may contain a
sequence.
Again, this difference rose from XACML's need to apply
functions to AttributeValues. It was difficult to define
standard functions that would apply to multiple
AttributeValues in a single Attribute, especially since SAML
has no requirement that each of the AttributeValues be
instances of the same schema.
XACML does permit a subject to have multiple values associated
with a single Attribute Identifier. This can be done by
specifying multiple Attribute instances, each having the same
Attribute Identifier.
There is a proposed work item for XACML 2.0 that would allow a
single Attribute having multiple AttributeValues (all of which
MUST be of the same DataType) to serve as a shorthand for
specifying a set of Attributes with the same Attribute
Identifier and DataType, but this would be only a shorthand
for existing semantics.
4. XACML inclusion of Issuer and IssueInstant
XACML was designed to accept attributes from multiple
sources, such as X.509 Attribute Certificates, database
entries, SAML Attribute Assertions, etc. Rather than force
each format to be converted into a SAML AttributeStatement,
XACML chose to extract the information considered necessary
for matching attribute values to policy requirements and
include all that information in a single, simple Attribute
definition.
The XACML TC maintained the SAML "string" type for Issuer,
although the XACML TC considers this inadequate and has
requested that SAML 2.0 contain a better definition for
Issuer. The Issuer should be a type/value pair, so that, for
example, Issuer X.500 names can be distinguished from company
identifiers or RFC822 names.
The XACML TC includes IssueInstant, but has no way of using
this value in a policy other than to require an exact match.
For example, there is no way in an XACML policy to say that a
particular Attribute is acceptable so long as it was issued
after a given dateTime. This reduces the value of
IssueInstant considerably, but this is an XACML issue and not
a SAML problem.
Anne
--
Anne H. Anderson Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]