The Shibboleth IdP V3 software has reached its End of Life and is no longer supported. This documentation is available for historical purposes only. See the IDP4 wiki space for current documentation on the supported version.

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

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

Current File(s): conf/c14n/subject-c14n.xml, system/conf/subject-c14n-system.xml

Format: Native Spring / Legacy Custom Schema

3.0 includes a concept called Subject Canonicalization, a process by which the IdP turns a non-simple representation of a subject identity (usually that of a user) into a simple username. This mechanism is applied when a SAML 1 NameIdentifier or SAML 2 NameID is passed into the IdP and needs to be transformed into a username. A common example of this use case is when an AttributeQuery message is received, and the IdP needs to recover the user's identity to pass into the attribute resolver.

Subject Canonicalization is implemented using Spring Web Flow. Each method of canonicalizing something into a username is implemented as a web flow and described using a bean that tells the IdP how to run that flow. The built-in flows handle all of the standard use cases for turning SAML names back into usernames, and little or no configuration is needed.

The subject-c14n.xml file includes the list of beans that describe the possible flows available, and some additional configuration.

You might modify this file to:

  • disable legacy compatibility with <PrincipalConnector> plugins in the attribute-resolver
  • enable and control the mapping of custom identifier Formats into usernames, such as email addresses or DNs

Compatibility Notes

In 2.x, the process of mapping SAML name identifiers back into usernames was managed using attribute-resolver.xml and <PrincipalConnector> plugins.

The IdP should load any existing 2.x attribute-resolver.xml file and configure itself in an expected manner, but the use of the legacy connectors 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 four beans that must have the following names:

  • shibboleth.SAMLSubjectCanonicalizationFlows
  • shibboleth.NameTransformFormats
  • shibboleth.NameTransformPredicate
  • shibboleth.NameTransforms

The first bean is a list of the descriptor beans that define the SAML canonicalization flows available to run. By default, it contains flows supporting legacy use of the attribute resolver, both memory- and crypto-based transient reversal, and non-functional stubs for mapping custom string-based identifiers back into usernames, optionally applying regular expression transforms. A commented out flow also exists for reversing storage-managed SAML 2 persistent identifiers.

The other three beans are used to configure the support for custom identifier mapping. The "shibboleth.NameTransformFormats" bean is a list of Format constants that the IdP will attempt to reverse-map, and includes a number of common SAML Formats. The "shibboleth.NameTransformPredicate" bean is a condition that must evaluate to true before the custom mapping flow can operate. By default, it is a condition based on the name of the relying party that has no valid inputs, and so always returns false. The "shibboleth.NameTransforms" bean is a list of regular expression and replacement string pairs that can transform an input value into a different value.

So in summary, if you want to allow reversing of transients (by the relying party they're issued to), do nothing. If you want to allow reversal of persistent IDs, they must be generated using a storage-based strategy (see NameIDGenerationConfiguration) and you must uncomment the "c14n/SAML2Persistent" bean reference. And if you want to support direct or nearly direct mapping of other Formats, you will need to populate the other three beans appropriately to reflect this. Note that this is generally a rare requirement.

Notes

Supported for the legacy <PrincipalConnector xsi:type="pc:StoredId"> is not present in the first alpha, see IDP-269.  As noted above, this mechanism is deprecated in V3 and should be replaced by edits to the conf/c14n/subject-c14n.xml file.  This restriction has been lifted and this connector will be available in all builds starting 01/July/2014

 


  • No labels