...
| Note |
|---|
Before continuing you should understand the concept of a name identifier and how to define and release attributes. |
Supporting a new name identifier within the identity provider is a three step processincludes:
- configure Configuring the IdP to produce the name identifierconfigure
- Configuring the IdP to accept the name identifier
- express support for the name identifier within the IdP's metadata
...
- (optional)
The second step
...
is occasionally important, but not necessarily mandatory, depending on the requirements of the relying parties you need to support. Specifically, the ability to reverse the identifier back into a user's identity is essential for supporting back-channel queries, among other features, but is not strictly needed for a one-way communication path such as is used by default with SAML 2.0 SPs. Most of the time, if you're just doing this to accomodate a vendor with a lousy SAML implementation, you can ignore that step.
Producing the Name Identifier
As discussed, name identifiers have different sets of properties (e.g. longevity, transparency). Therefore it should come as no surprise that there are multiple ways in which to produce the name identifier depending on which properties are required.
...
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
NameIdentifierare 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:
...