...
| 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.
...
An IdP can express support for a name identifier format through its metadata. This is done by adding a <NameIDFormat> element to both the IdP's IDPSSODescriptor and AttributeAuthorityDescriptor roles. The value of this element should be the format as configured in the name identifier attribute encoder.
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat> |
...