The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

IdPCustomNameIdentifier

Custom Name Identifier

Custom name identifiers have the following properties:

Property

Value

longevity

arbitrary, but usually somewhat long-lived

transparency

arbitrary

targeted

not usually

revokable

by default, the IdP isn't able to reverse the mapping at all

reassignable

arbitrary

Define the Attribute

A custom name identifier is typically created in two steps:

  1. Create an attribute definition to use as the basis of the identifier. This can be done directly on top of a raw source attribute or a higher-level attribute definition. The IdPAddAttribute topic includes information on this step.
  2. Attach SAML 1 Name Identifier and/or SAML 2 NameID attribute encoders to the attribute definition.
Custom Name Identifier Attribute Definition
<resolver:AttributeDefinition id="customId" xsi:type="Simple" sourceAttributeID="uid"
xmlns="urn:mace:shibboleth:2.0:resolver:ad">

<resolver:Dependency ref="DEFINITION_ID_1" />

<resolver:AttributeEncoder xsi:type="SAML1StringNameIdentifier"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

<resolver:AttributeEncoder xsi:type="SAML2StringNameID"
xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
nameFormat="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" />

</resolver:AttributeDefinition>

The nameFormat choice is essentially arbitrary. SAML defines a few poorly specified options for some common syntaxes like email addresses or distinguished names, but in many cases the best choice is to invent a format that you control, or if you must, use the "unspecified" option as above.

The example above is merely one approach. Anything you can attach the necessary encoders to can be turned into an identifier, as long as you're willing to break the reverse mapping capability of the IdP or produce the necessary PrincipalConnector yourself.

Release the Attribute

Finally, define an attribute filter policy that releases the internal attribute to the intended relying parties.

Attribute Filter Policy Releasing Transient ID to Anyone
<AttributeFilterPolicy id="releaseCustomIdToPartner">

<PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://sp.example.org/shibboleth" />

<AttributeRule attributeID="customId">
    <PermitValueRule xsi:type="basic:ANY" />
</AttributeRule>

</AttributeFilterPolicy>