Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

The Relationship of Name Identifiers and Attributes

Background

In SAML 1 the IdP was the sole arbiter of which name identifier was used for a user at any given point. Prior to the SAML 1 extensions for SAML metadata there wasn't a standard way for the SP to suggest which type, known as formats in SAML, of name identifiers it supported. SAML 2 however introduced not only SAML metadata, which allows entities to indicate which formats they support, but also added the ability for an SP to require a particular format.

Attributes and Name Identifiers

Shibboleth 2 takes the approach that a name identifier is just one of the collective set of attributes that make up your digital identity. This attribute just happens to be encoded a bit differently than some of the other attributes, but this encoding doesn't actually change the content being presented. For example:

Email as a Name Identifier
<NameID format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">jsmith@example.org</NameID>

is the same data as

Email as an Attribute
<Attribute Name="urn:oid:0.9.2342.19200300.100.1.3" FriendlyName="mail">
   <AttributeValue>jsmith@example.org</AttributeValue>
</Attribute>

It naturally followed that a deployer should then have the full power of the attribute resolution process available when constructing name identifiers. This has two main benefits. First, it allows the deployer to use arbitrarily complex, or specialized, logic for the creation of the name identifier, allowing them to tailor it to their particular environment. Second, it allows the deployer to determine which entities get which name identifiers via the attribute filter policies. So the deployer is provided a unified model for pulling, preparing, and releasing data to the relying party.

  • No labels