[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]