A name identifier,
<NameIdentifier> in SAML 1 and
<NameID> in SAML 2, is generally used to identify the person that the IdP has issued an assertion about. Name identifiers can be anything; an email address or a Kerberos principal name are common, every-day examples of such information.
Name identifiers come in different types, known as formats. All formats have the following two properties: scope and reversibility. Scope means that any given identifier is issued from, and only makes sense within, a given domain. A name identifier without a scope is meaningless, because it could have come from any IdP in the world. For example, saying just the name identifier '123456' is meaningless, but saying '123456' from 'https://idp.example.org' provides the requisite scope and makes the identifier meaningful. Reversibility is the ability for an IdP to translate the identifier back into the precise user within the lifetime of the identifier. This is necessary to support things like attribute queries.
Name identifiers can also be described by the following characteristics:
- longevity - the length of time for which the name identifier is good. The lifetime of most name identifiers fall in to one of three categories:
- transient: identifiers which are only good for a brief period of time (e.g. 5 minutes)
- persistent: identifiers which are good for a long period of time (e.g. years) but which the IdP may revoke
- permanent: identifiers which are good for the lifetime of an account and hence may not be revoked by the IdP
- transparency - the ability of a recipient to identify the user from the name identifier. The transparency of most name identifiers can be described as either:
- opaque: the recipient cannot determine anything about the precise user from the identifier. Type 3-5 UUIDs are an example of such an identifier.
- transparent: the recipient can easily determine the user from the identifier. Most email addresses are an example of this type of identifier.
- targeted - whether the name identifier is meant for a specific relying party, or relying party group, and not for anyone else
- revocable - whether a given name identifier can be revoked
- reassignable - whether a given name identifier, once revoked, may be re-assigned to some one else
The Relationship between Name Identifiers and Attributes
In SAML 1, the IdP was the sole arbiter of which name identifier was used with a relying party. SAML 2, however, introduced SAML metadata, which allows entities to indicate which formats they support, and the ability for a service provider to require a particular format on a per-request basis.
Attributes and Name Identifiers
The properties above used to describe name identifiers could equally apply to attributes. However, it is important to note that attributes are not required to be scoped or reversible as is the case with name identifiers. In most cases, in fact, they are neither scoped nor reversible.
Because of their similarities though, Shibboleth 2 considers the name identifier to simply be part of the collective set of attributes that makes up a digital identity. Such "name identifier attributes" are encoded differently from the other attributes, but this encoding does not actually change the content being presented. For example:
is the same data as
With Shibboleth 2 treating the name identifier as an attribute, the deployer has 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 attribute resolution logic to create name identifiers thus allowing the deployer to tailor the identifier to their particular environment. Second, it allows the deployer to determine which relying parties get which name identifiers via attribute filter policies.
Note, however, that using this mechanism does not magically convey the reversibility property on an attribute. Whichever attribute is chosen to be encoded as the name identifier must already have this property. The encoding process does, however, add the scoped property and is not something that a deployer must explicitly configure.