Linking Identities by Using Authentication Trees or Chains

Identity providers and service providers must be able to communicate about users. Yet, in some cases, the identity provider chooses to communicate a minimum of information about an authenticated user; for example, a generated, opaque NameID that cannot directly be used to locate to an identity in the SP identity store.

AM can use these pseudonym identifiers for establishing links between otherwise unrelated accounts, by requiring that the user authenticates to the SP using a linking authentication tree or chain.

The following list describes the sequence of events that occurs the first time a user attempts to authenticate to the AM service provider, when a linking authentication chain or the equivalent authentication node(s) are configured:

  1. Accessing the service provider.

    A user attempts to access a service and is redirected to the AM server acting as the service provider, specifying one of the following in the login URL:

    • An authentication chain containing the "SAML2 Authentication Module".

      For example, https://www.sp.com:8443/openam/XUI/#login/&service=spSAMLChain.

    • An authentication tree containing the "SAML2 Authentication Node".

      For example, https://www.sp.com:8443/openam/XUI/#login/&service=spSAMLTree.

  2. Authentication at the identity provider.

    AM redirects the user to the identity provider. The user authenticates successfully at the identity provider. The identity provider returns a SAML assertion to the SP.

  3. Service provider attempts to access a federated identity.

    AM attempts to locate the identity in its own user store. No link between the IDP identity and a local one is found.

  4. Invocation of the linking chain, or equivalent authentication node(s).

    As no link is found, AM does one of the following:

    • (Authentication chains) Invokes a linking authentication chain to determine which local user account to use.

    • (Authentication trees) Goes through a path in the authentication tree that lets the user authenticate on the SP.

  5. Identity federation.

    After successful authentication at the SP, AM then writes the name ID from the assertion into the local user's profile, creating a permanent link between the two identities.

    For more information on creating permanent links between identities, see "Persistent or Transient Federation".

The following list describes the sequence of events that occurs during subsequent authentication attempts, after the user's identities on the identity and service providers have been federated:

  1. Accessing the service provider.

    A returning user attempts to access their service and is redirected to the AM server acting as the service provider. Their login URL specifies one of the following:

  2. Authentication at the identity provider.

    AM redirects the user to the identity provider, and the user authenticates successfully at the identity provider. The identity provider returns a SAML assertion to the SP.

  3. Service provider attempts to access a federated identity.

    AM attempts to locate the name ID in its user store. The search for the name ID succeeds.

    As there is a match, the user does not need to log in to the SP, and is given access to the service.

Configure Authentication Trees or Chains to Link Accounts

To configure AM to link accounts, see the following options:

Configure Authentication Trees to Link Accounts

Configure Authentication Chains to Link Accounts

To Link Identities by Using a Linking Authentication Chain

This procedure demonstrates how to link identities by using a linking authentication chain on the SP to identify the local user.

Before attempting to configure a linking authentication chain, ensure that you have configured AM for SAML v2.0, created the identity and service providers, and configured a circle of trust. You must also have configured AM to support single sign-on. For information on performing those tasks, see Deployment Considerations and Implementing SSO and SLO.

  1. On the hosted service provider, log in to the AM console as an administrator, such as amAdmin.

  2. Create an authentication chain; for example, named myLinkingChain. This chain is used to identify the user account in the SP to link to the account in the IDP. The chain can use any of the available methods for authentication as required; for example, multi-factor authentication.

    For more information on creating authentication chains, see Configuring AM for Authentication.

  3. If you are using integrated mode SSO:

    1. Navigate to Realms > Realm Name > Authentication > Modules, and then select the module name of your SAML2 authentication module.

    2. In the Linking Authentication Chain field, enter the name of the authentication chain you created earlier; for example, myLinkingChain.

    3. Save your work.

  4. If you are using standalone mode SSO:

    1. Navigate to Realms > Realm Name > Authentication > Settings > Core.

    2. In the Organization Authentication Configuration property, select the authentication chain you created earlier; for example, myLinkingChain.

    3. Save your work.

      For more information on setting the default chain for a realm, see Configure Sensible Default Authentication Services.

  5. To test your work, initiate single sign-on; for example, as described in "SP-Initiated SSO JSP".

    Authenticate to the IDP as the demo user. You will then be redirected to the SP and asked to authenticate using the linking authentication chain specified. If persistent linking is enabled (the default), then initiating single sign-on a second time will require authentication only to the IDP.

Read a different version of :