OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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]