MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: SAML vs XACML Attributes
Not only could I not find the older e-mail describing this issue,
but I have discovered that I was mistaken about the current SAML
2.0 status. So this is a new presentation of the situation.
Contents
========
Pre-2.0 XACML Attributes
Pre-2.0 SAML Attributes
SAML 2.0 Attributes
Mapping SAML Attributes to XACML Attributes
XACML 2.0 Attribute Options
Anne's Opinion
Pre-2.0 XACML Attributes
========================
XACML uses three (ignoring IssueInstant) XML attributes to
identify Attributes:
- AttributeId - the Attribute's name; a unique identifier.
Type="anyURI"
- DataType - the syntax of the Attribute's value.
Type="anyURI".
- Issuer - [optional] the identity of the authority that bound
this Attribute value to its subject (which might be an XACML
Subject, Resource, or Action). Type="string".
XACML's Request Context is designed to be an abstraction layer,
allowing various types of attributes from various sources to be
referenced and manipulated using a common mechanism. It is the
job of the XACML Context Handler to map attributes from various
repositories that use a variety of naming and structuring
mechanisms into the abstract XACML Attribute format. Since we
could see no case in which an Attribute name would be used
independently from its namespace, we defined "AttributeId" to be
a single value that includes any qualifying information needed to
disambiguate the name.
In order to reference an Attribute, the Policy needs to specify
only the AttributeId, the Datatype, and, optionally, the Issuer.
Pre-2.0 SAML Attributes
=======================
Pre-2.0, SAML uses two XML attributes to identify Attributes:
- AttributeNamespace [Required]
(was earlier called NameQualifier) The namespace in which the
AttributeName elements are to be interpreted. Type="anyURI".
- AttributeName [Required]
The name of the attribute. Type="string".
The syntax (DataType) of the Attribute's value is determined by
the XML element tag on the AttributeValue itself. The Issuer is
specified in the Assertion containing the Attribute.
SAML 2.0 Attributes
===================
The SSTC has discovered that "AttributeNamespace" is being used
for multiple dimensions of aggregation:
- Identity of the repository from which the Attribute was to be
retrieved
- Standards group or Profile in which the AttributeName was
defined
- Application within which the AttributeName was defined
- An XML namespace that qualified the AttributeName's schema
definition.
The current SSTC solution (SAML 2.0 Draft 08) has the following
definition for Attribute:
<element name="AttributeDesignator" type="saml:AttributeDesignatorType"/>
<complexType name="AttributeDesignatorType">
<attribute name="Name" type="string" use="required"/>
<attribute name="NameFormat" type="anyURI" use="required"/>
<attribute name="ValueType" type="anyURI" use="optional"/>
</complexType>
<element name="Attribute" type="saml:AttributeType"/>
<complexType name="AttributeType">
<complexContent>
<extension base="saml:AttributeDesignatorType">
<sequence>
<element ref="saml:AttributeValue" minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Source" type="string" use="optional"/>
<anyAttribute>
</extension>
</complexContent>
</complexType>
<element name="AttributeValue" type="anyType"/>
where the spec defines:
Name [Required]
The name of the attribute. Type="string".
NameFormat [Required]
A URI reference representing the classification of
the attribute name for purposes of interpreting the name.
See Section 7.x for some URI references that MAY be used as
the value of the NameFormat attribute and their associated
descriptions and processing rules. If no NameFormat value
is provided, the identifier
urn:oasis:names:tc:SAML:2.0:attname-format:unspecified (see
Section 7.x) is in effect. Type="anyURI".
ValueType [Optional]
A URI reference representing the datatype of the desired or
supplied attribute. If no ValueType value is provider, the
idenfier
urn:oasis:names:tc:saml:2.0:valuetype-format:appSpecific
(see Section 7.x) is in effect. Note that the datatypes
specified on the <AttributeValue> element using xsi:type
have no SAML-defined relationship with ValueType. The
ValueType setting (default or explicit) in an attribute
query using the <AttributeDesignator> element MUST be
exactly matched (in addition to other exact matches as
described in Section x) in order for an attribute to be
returned. Type="anyType".
...
Source [Optional]
The source location or database from which the attribute
came. Interpretation of the source information is
application-specific. Type="string".
<AttributeValue> [AnyNumber]
The value of the attribute. If an attribute contains more
than one discrete value, it is RECOMMENDED that each value
appear in its own <AttributeValue> element. If the
attribute exists but has no value, then the <AttributeValue>
element MUST be omitted. If more than one <AttributeValue>
element is supplied for an attribute, and any of the
elements have a datatype assigned through xsi:type, then all
of the <AttributeValue> elements must have the identical
datatype assigned.
Arbitrary attributes
This complex type uses an <xsd:anyAttribute> extension point
to allow for arbitrary XML attributes to be added to
<Attribute> constructs without the need for an explicit
schema extension. This allows additional fields to be added
as needed to supply the context in which the attribute
should be understood. SAML extensions MUST NOT add local
(non-namespace-qualified) XML attribuets to the
AttributeType complex type or to any element bound to this
type or a derivations of it; such attributes are reserved
for future maintenance and enhancement of SAML itself.
Mapping SAML Attributes to XACML Attributes
===========================================
For pre-2.0 SAML Attributes, the XACML Context Handler has to
somehow convert the combination of "AttributeNamespace" and
"AttributeName" to a single, unique "AttributeId". The default
way of doing this is to concatenate the two values, using some
appropriate character (depends on the AttributeNamespace anyURI
scheme) as a separator. The DataType has to be obtained from the
type of the SAML AttributeValue element tag. The Issuer can be
pulled from the SAML Assertion.
For Draft 08 SAML 2.0 Attributes, the XACML Context Handler has
to convert the combination of "Name", "NameFormat", and possibly
"Source" to a single, unique "AttributeId". Again, the default
way of doing this will probably be to concatenate the values,
although whether "Source" would come first or second is unclear.
Alternatively, the Context Handler SHOULD be supplied with a
mapping from each combination of SAML Attribute name components
to a unique XACML AttributeId. This mapping need not use
concatenation, and the names may actually be very different.
If the SAML Attribute has a "ValueType" XML attribute, then that
value should be used as the XACML DataType. If "ValueType" is
missing, then I recommend:
a) If AttributeValue type corresponds to one of the XACML
primitive types, then DataType = the XACML primitive type.
b) Otherwise, DataType = the fully-qualified name of the
top-level element comprising the "AttributeValue" value.
XACML AttributeValue value is then the SAML AttributeValue value
with the top-level element tags stripped off.
XACML 2.0 Attribute Options
===========================
1. XACML could define its Attribute to contain exactly the same
XML attributes as the SAML 2.0 definition.
This makes mapping easy for SAML Attributes, but maybe harder
for non-SAML Attributes. It also makes XACML
AttributeDesignators more complex.
2. XACML 2.0 Attributes could contain the two required SAML
attributes, or the two required attributes plus Source.
Same arguments as for #1, except that SAML Attributes that use
XML attributes not supported in XACML will have to have an
application-specific mapping defined for the Context Handler.
3. XACML 2.0 Attributes could keep their current one-part form
and continue to depend on default concatenation augmented with
optional application-specific mappings for the Context
Handler.
In any case, I recommend that XACML 2.0 Attribute add an
additional XML element for IssuerNameFormat.
Anne's Opinion
==============
SAML 2.0 Draft 08 has not really helped the situation at all.
The model seems to be that NameFormat maps to a schema
specification (or surrogate) in which the name is defined, but
the definition is unclear enough that I think it is likely to be
mis-used. Source is also problematic: is source a "database
type" or a specific database repository location? Also, since
Source is of type "string", there is the possibility of name
collisions. Finally, they allow "Arbitrary attributes", which
are guaranteed to be used in non-interoperable ways.
I now think XACML should support any SAML XML attribute that has
clearly defined semantics, and none that do not. The cost in
greater complexity for AttributeDesignators is minimal.
I think the XACML TC needs to continue to push back on the SSTC
to produce clearly defined semantics for each supported XML
attribute, and recommend that SAML 2.0 NOT support "Arbitrary
attributes".
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]