...
Expressing Support in Metadata
The An IdP expresses can express support for a name identifier format through its metadata. This is done by adding a new NameIDFormat
<NameIDFormat>
element to both the IdP's IDPSSODescriptor
and AttributeAuthorityDescriptor
roles. The value of this element should be the name format as configured in the name identifier attribute encoder.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
|
In practice, little if any software uses this information, so other than being useful as a documentation aid, it's not usually important to do this.
IdP Name Identifier Selection Process
An identity provider can be is often configured to produce multiple types of name identifiers. The process by which the IdP selects the name identifier format to use for a given relying party involves two steps.
...
- The attributes are filtered by the protocol used to contact the IdP. If SAML 1 was used, then only attributes that may be encoded as a SAML 1
NameIdentifier
are retained; likewise for SAML 2. - The remaining attributes are filtered by the name identifier formats listed as supported in the SP's metadata, if any. Note that the IdP treats the "unspecified" format defined by SAML as a wildcard and if it appears in an SP's metadata, the IdP will assume that the SP can accept any format it produces.
If no attributes remain after the filtering step, no name identifier is generated. Otherwise, the IdP moves on to the second stage: selection of a single attribute from the set of possible attributes. It does so using the following steps:
...