Versions Compared

Old Version 1

changes.mady.by.user Scott Cantor

Saved on

compared with

New Version Current

changes.mady.by.user Scott Cantor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

To support a custom identifier Format, take the following steps:

  1. Determine the Format constant you need to support (note that most of the constants used in SAML contain a "1.1" in the URN and apply to both SAML versions).

    1. If the type of data you want to populate doesn't fit a standard Format, the soundest advice is to use the URI name of the SAML Attribute that applies to the data as the Format.

  2. Choose one or more IdP attributes to use to supply the identifier's value (e.g. "mail"). The first value found (in order listed) will be used.

  3. Configure your attribute filter policy to release the attribute(s) chosen to the relevant SP(s) in whatever way you prefer.

  4. Uncomment or create a generator bean in saml-nameid.xml for SAML 1 and/or SAML 2 as required.

    SAML 2.0 E-Mail Format Example

    Code Block
    languagexml
    <util:list id="shibboleth.SAML2NameIDGenerators">
	<ref bean="shibboleth.SAML2TransientGenerator" />

	<!-- SAML 2 EXAMPLE -->
    <bean parent="shibboleth.SAML2AttributeSourcedGenerator"
		p:omitQualifiers="true"
		p:format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"
		p:attributeSourceIds="#{ {'mail', 'othermail'} }" />
</util:list>

    The format property is self-explanatory and must contain a single value per bean. The attributeSourceIds property is a list of attribute IDs to source the value from (the first value found will be used), and you can embed a comma-delimited list of quoted IDs inside the double braces (see SpringConfiguration). Most custom formats in SAML (and otherwise) should leave out the SAML-defined NameQualifier and SPNameQualifier XML attributes and there's a property per above that needs to be set to suppress them.

  5. Lastly, trigger the appropriate Format to be selected by manipulating the selection process described in the NameIDGenerationConfiguration topic.

    1. If you control the SP's metadata (which is very common when this use case arises), the best way to do this is by inserting a <NameIDFormat> element into the metadata.

    2. If you don't control the metadata, then you can add such an element using a NameIDFormatFilter.

    3. As a last resort, a nameIDFormatPrecedence profile configuration property can be applied in a relying party override definition or via MetadataDrivenConfiguration. This is almost certainly more work than the previous two options and should be avoided.

The process above requires that you explicitly release the attribute to use as a source in your filter policy. If you wish, you can avoid this step by using a generator property (useUnfilteredAttributes) that allows an unreleased attribute to be used as a source, but note that doing so creates a sort of "pseudo-policy" exposing information to an SP outside of the normal filtering process, so it can be tricky later to realize what's actually been released to that SP.

...