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 2 Next »

Legacy File(s): conf/attribute-resolver.xml

Current File(s): conf/saml-nameid.xml, idp.properties, system/conf/saml-nameid-system.xml

Format: Native Spring / Legacy Custom Schema

Formally this is the configuration of the "NameIdentifierGeneration" service.

The saml-nameid.xml file is used to control the generation of SAML 1 NameIdentifier and SAML 2 NameID content. SAML assertion subjects contain a special slot for an identifier that is less commonly used in Shibboleth deployments (because SAML Attributes are more general and useful) but is very commonly used by vendors seeking to do the bare minimum necessary to support SAML.

You might modify this file to:

  • add support for more application-oriented NameID types, such as email addresses

Compatibility Notes

The 3.0 IdP supports a new dedicated service for configuring NameID generation, and the legacy 2.x approach of encoding attributes into identifiers using attribute-resolver.xml and special attribute encoders that generate NameIdentifiers or NameIDs instead of Attributes.

The IdP should load any existing 2.x attribute-resolver.xml file and configure itself in an expected manner, but that configuration will be superseded by the content of the new saml-nameid.xml file and will fall back to the resolver only as a backstop. You can short-circuit the new functionality by commenting out the content of the two generator lists.

The use of the legacy attribute encoders is deprecated in this release, and deployers are urged to migrate their configurations to native Spring syntax after or while upgrading.

Contents

The configuration defines two beans that must have the following names:

  • shibboleth.SAML2NameIDGenerators
  • shibboleth.SAML1NameIdentifierGenerators

Each is a Spring list containing any number of generator plugins of the appropriate SAML version. Each plugin is specific to an identifier Format, a SAML constant that identifies the kind of value being expressed.

The generation process involves selecting a list of Formats to try and generate, and then attempting each one until one is obtained. The Format determination is based on combining the SP's request, its metadata, and the nameIDFormatPrecedence property, if set for the matching relying party configuration. Default Formats are set via idp.properties in the event that nothing else is called for.

The default configuration includes generators for transient identifiers, and for SAML 2, persistent identifiers. These plugins are configured using idp.properties that control the strategies used to generate and store the values.

The default configuration also demonstrates how to generate a custom identifier using an arbitrary Format based on an attribute from the attribute resolution process. This mirrors the older approach of encoding attributes, but separates the two operations in the configuration. This plugin also has the capability, unlike the resolver-based approach, of selecting the first value from a set of possible source attributes.

The impact of this default is such that IF the source attribute ("email" in the example) were to be released to an SP, AND the Format determination were to result in the "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" Format being selected,

  • No labels