Access Management 7.3.2

SSO and SLO in integrated mode

Authentication nodes and trees support SSO in integrated mode only. The SAML2 Authentication node handles the SAML v2.0 authentication flow, but relies on other nodes.

Integrated mode flow (trees)
SAML v2.0 Integrated Mode Flow
Figure 1. SAML v2.0 Integrated Mode Flow

  1. An unauthenticated user initiates authentication to an AM SAML v2.0 service provider. The login URL references an authentication tree that includes a SAML2 authentication node. For example, https://openam.example.com:8443/openam/XUI/?service=mySAM2LTree.

  2. If there are any authentication nodes that precede the SAML2 Authentication node, AM executes them.

  3. The SAML2 authentication node processing begins.

  4. The authentication node requests an assertion from the IDP. The configuration of the SAML2 Authentication node determines the details of the request.

    If the user is not authenticated in the IDP, the IDP will request them to authenticate.

  5. The IDP responds to the SP with a SAML assertion.

  6. If the SAML assertion contains a non-transient name ID, AM searches the identity store, attempting to locate a user with the same name ID.

    If the name ID for the account exists, the tree ends in the success node.

    If the name ID does not exist…​

  7. ... and a Create Object node (or a Provision Dynamic Account node for standalone AM environments) is configured in the tree, it creates a new account in the SP using auto-federation, including the name ID in the user profile.

  8. ... and method of authenticating the user is available in the tree, a Write Federation Information node writes the persistent name ID in the user profile.

    For more information about linking when autofederation is not configured, see Link identities for authentication.

Authentication chains support SSO and SLO in integrated mode, whereby the SAML2 authentication node handles all of the SAML v2.0 authentication flow.

Integrated mode flow (chains)
SAML v2.0 Integrated Mode Flow
Figure 2. SAML v2.0 Integrated Mode Flow

  1. An unauthenticated user initiates authentication to an AM SAML v2.0 service provider. The login URL references an authentication chain that includes a SAML2 authentication module. For example, https://openam.example.com:8443/openam/XUI/?service=mySAMLChain#login/.

  2. If there are any authentication modules that precede the SAML2 module in the authentication chain, AM executes them.

  3. SAML2 authentication module processing begins.

  4. The authentication module requests an assertion from the identity provider. The SAML2 module’s configuration determines the details of the request.

If the user is currently unauthenticated on the identity provider, the following three steps occur:

  1. The identity provider requests credentials from the user.

  2. The user provides their credentials.

  3. Authentication succeeds (assuming the user provided valid credentials).

Processing continues as follows:

  1. The identity provider responds to the service provider with a SAML assertion.

  2. If the SAML assertion contains a non-transient name ID, AM searches the user datastore, attempting to locate a user with the same name ID.

The flow varies here.

The following event occurs if the following are true:

  • The name ID for the user is not found in the datastore

  • Dynamic profile creation is configured in the Core Authentication Service

  • Auto-federation is enabled on the service provider

    1. AM adds an entry for the user to the user datastore. Even if a linking authentication chain has been configured, it is not invoked. The user is not prompted to authenticate to the service provider.

The following two events occur if the following are true:

  • The name ID for the user is not found in the datastore

  • A linking authentication chain has been configured in the SAML2 authentication module

  • Dynamic profile creation is not configured in the Core Authentication service

  • Auto-federation is not enabled on the service provider

    1. The SAML2 authentication module invokes the linking authentication chain, requiring the user to authenticate to the service provider.

    2. After successfully completing the linking authentication chain, AM writes the persistent name ID obtained in the SAML assertion sent by the identity provider into the user’s profile.

At this point, SAML2 authentication module processing ends. The remaining events comprise completion of the primary authentication chain:

  1. If there are any authentication modules remaining in the chain, AM executes them.

  2. Authentication is complete.

Implement SAML v2.0 single sign-on in integrated mode

The following list is an overview of the activities you perform when implementing SAML v2.0 single sign-on in integrated mode:

  1. Preparing entity providers and a circle of trust, and changing several endpoints in the service provider configuration.

    See Configure AM for integrated mode.

  2. Configuring a tree that contains, at least, the SAML2 authentication node.

    See Create accounts dynamically during federation (standalone AM) and Create accounts dynamically during federation.

Configure AM for integrated mode

  1. If you have not already done so, configure SAML v2.0 by performing the tasks listed in Deployment considerations.

  2. In the AM admin UI, create a hosted service provider by following the steps in Create a Hosted Entity Provider.

    Ensure that you have configured the attribute map (Assertion Processing > Attribute Mapper). It determines how AM will map assertion attributes coming from the IDP to the user’s profile on the SP.

    During the authentication process, the mapping is used to find existing users on the SP, and to create or update user accounts on the SP.

  3. Configure a remote identity provider by following the steps in Import and Configure a Remote Entity Provider.

    When you specify the circle of trust for the IDP, use the Add to Existing option and specify the circle of trust that you created when you created the hosted service provider.

  4. Change the Assertion Consumer Service locations in the hosted service provider configuration.

    The default locations support standalone mode. Therefore, you must change the locations when implementing integrated mode.

    Change the locations as follows:

    • In the AM admin UI, go to Realms > Realm Name > Applications > Federation > Entity Providers > SP Name > Services > Assertion Consumer Service.

    • Change the location of the HTTP-Artifact consumer service to use AuthConsumer, rather than Consumer. For example, if the location is https://www.sp.com:8443/openam/Consumer/metaAlias/sp, change it to https://www.sp.com:8443/openam/AuthConsumer/metaAlias/sp.

    • Similarly, change the location for the HTTP-POST consumer service to use AuthConsumer rather than Consumer.

      Note that you do not need to change the location for the PAOS service because integrated mode does not support the PAOS binding.

    • The results will resemble the following:

      Editing the Consumer Service URLs for Integrated Mode.

      Save your changes. Now you are ready to configure authentication trees.

Create accounts dynamically during federation (standalone AM)

In integrated mode, the SP can use authentication trees to tailor the authentication experience to users. You can create very complicated trees, or even multiple trees to satisfy the requirements of your organization.

The example shown in this procedure uses the SAML v2.0 node to request an assertion from the IDP, and then creates an account for the user in the SP, if one does not exist.

If you are not using auto-federation, you can also use authentication trees to create persistent links between user accounts.

Perform the following steps to configure a tree similar to the following:

Example Tree with SAML2 Authentication Node
Figure 3. Example tree with SAML2 Authentication node

  1. Add a SAML2 Authentication node.

    Integrated mode is SP SSO-initiated only, and SLO is not supported.

    The node processes the assertion, makes its contents available to the authentication tree’s state in the userInfo object, and tries to map the assertion’s nameID using the uid mapping in the SP’s assertion map.

    If the node finds a match, the tree continues through the Account Exists output. Otherwise, the tree continues through the No Account Exists output.

  2. Add a Provision Dynamic Account node to the No account exists outcome.

  3. (Optional) If you have not configured auto-federation, you can add the Write Federation Information node to create a persistent link between the accounts.

    For examples, see Link identities by using authentication trees.

Create accounts dynamically during federation

In integrated mode, the SP can use authentication trees to tailor the authentication experience to users. You can create very complicated trees, or even multiple trees to satisfy the requirements of your organization.

The example shown in this procedure uses the SAML v2.0 node to request an assertion from the IDP, and then creates an account for the user in the SP if one does not exist.

If you are not using auto-federation, you can also use authentication trees to create persistent links between the user accounts.

Perform the steps in this procedure to configure a tree similar to the following:

Example Tree to Create Accounts Dynamically
Figure 4. Example tree to create accounts dynamically

  1. Add a SAML2 Authentication node.

    Integrated mode is SP SSO-initiated only, and SLO is not supported.

    The node processes the assertion, makes its contents available to the authentication tree’s state in the userInfo object, and tries to map the assertion’s nameID using the uid mapping in the SP’s assertion map.

    If the node finds a match, the tree continues through the Account Exists output. Otherwise, the tree continues through the No Account Exists output.

    Note that the attribute the node uses to map the nameID is not configurable, and this example adds nodes to process the userInfo object and match its contents to the managed user’s schema.

  2. Add a Scripted Decision node to copy the information from the assertion to the authentication tree’s shared state.

    Example script 
    outcome = "true";
if (sharedState.get("userInfo")) {
if (sharedState.get("objectAttributes")) {
sharedState.remove("objectAttributes");
}
var userName=null,sn=null,mail=null;

    try { userName=sharedState.get("userInfo").get("attributes").get("uid").get(0).toString(); } catch (e) {}
    try { sn=sharedState.get("userInfo").get("attributes").get("sn").get(0).toString(); } catch (e) {}
    try { mail=sharedState.get("userInfo").get("attributes").get("mail").get(0).toString(); } catch (e) {}

  sharedState.put("objectAttributes", {"userName":userName,"sn":sn,"mail":mail});
}

    For more information, see Scripted decision node API.

  3. Add an Identify Existing User node to search the user with the appropriate attribute.

    For example, userName.

  4. Complete the tree adding the required nodes to create the new account if it does not exist on the SP.

    The scripted decision node that you created before gathering the attributes that are now available to create the account. However, these may not be enough to satisfy your managed user rules. To ensure that the required attributes are available, use the Required Attributes Present node to check them, and the Attribute Collector node to collect the ones missing.

    Finally, to create the account, use the Create Object node.

    Ensure that you configure the appropriate identity resource in this node. For example, managed/alpha_user.

  5. (Optional) If you have not configured auto-federation, you can add the Write Federation Information node to create a persistent link between the accounts.

    For examples, see Link identities by using authentication trees.

Implement SSO in integrated mode (chains)

The following list is an overview of the activities you perform when implementing SAML v2.0 single sign-on in integrated mode:

  • Preparing entity providers and a circle of trust.

  • Changing several endpoints in the service provider configuration.

  • Configuring a SAML2 authentication module and including it in an authentication chain.

  • Deciding if and how you want to federate identities during authentication. In integrated mode, you can either create user entries dynamically, or you can configure a linking authentication chain that authenticates users at the service provider after successful authentication at the identity provider, and then federates the identity.

The following procedure provides step-by-step instructions for performing these activities.

Implement SAML v2.0 single sign-on in integrated mode

  1. If you have not already done so, configure SAML v2.0 by performing the tasks listed inDeployment considerations.

  2. In the AM admin UI of the SP, create a hosted service provider by following the steps in Create a hosted entity provider.

  3. Configure a remote identity provider by following the steps in Import and configure a remote entity provider.

    When you specify the circle of trust for the IDP, use the Add to Existing option and specify the circle of trust that you created when you created the hosted service provider.

  4. Change the Assertion Consumer Service locations in the hosted service provider configuration.

    The default locations support standalone mode. Therefore, you must change the locations when implementing integrated mode.

    Change the locations as follows:

    • In the AM admin UI, go to Realms > Realm Name > Applications > Federation > Entity Providers > SP Name > Services > Assertion Consumer Service.

    • Change the location of the HTTP-Artifact consumer service to use AuthConsumer, rather than Consumer. For example, if the location is https://www.sp.com:8443/openam/Consumer/metaAlias/sp, change it to https://www.sp.com:8443/openam/AuthConsumer/metaAlias/sp.

    • Similarly, change the location for the HTTP-POST consumer service to use AuthConsumer rather than Consumer.

      Note that you do not need to change the location for the PAOS service because integrated mode does not support the PAOS binding.

    • The results will resemble the following:

      Editing the Consumer Service URLs for Integrated Mode.

      Save your changes.

  5. Create a SAML2 authentication module:

    • In the AM admin UI, go to Realms > Realm Name > Authentication > Modules, and select Add Module.

    • Specify a name for the module, specify the module type as SAML2, and select Create.

    • Configure the SAML2 authentication module options. See SAML2 Authentication Module for detailed information about the configuration options.

      You must set a value for the Linking Authentication Chain property, specifying the authentication chain that will be invoked.

    • Save your changes.

  6. Create an authentication chain that includes the SAML2 authentication module that you created in the previous step.

  7. Test your configuration.

    First, clear your browser’s cache and cookies. Then, attempt to log in to AM using a login URL that references the authentication chain that includes the SAML2 module. For example, https://www.sp.com:8443/openam/XUI/#login/&service=mySAMLChain.

    AM will redirect you to the identity provider for authentication.

    If required, you can now configure AM to link identities in the IDP with those in the SP, generate new accounts on the SP, or link to a shared account; for example anonymous. For more information and instructions, see Federate identities.

Configure SLO in integrated mode (chains)

Use the following two options to control single logout in integrated mode:

  • The post-authentication processing class for the authentication chain that includes the SAML2 authentication module. You configure post-authentication processing classes by navigating to Realms > Realm Name > Authentication > Chains > Chain Name > Settings.

  • The Single Logout Enabled option in the SAML2 authentication module configuration.

Configure these options as follows:

Configure Single Logout Options
Requirement Configuration

Single logout occurs when a user initiates logout at the identity provider or at the service provider.

Set the post-authentication processing class for the authentication chain that contains the SAML2 authentication module to org.forgerock.openam.authentication.modules.saml2.SAML2PostAuthenticationPlugin.

Set the Single Logout Enabled option to true in the SAML2 authentication module configuration.

Single logout occurs only when the user initiates logout at the identity provider.

Set the post-authentication processing class for the authentication chain that contains the SAML2 authentication module to org.forgerock.openam.authentication.modules.saml2.SAML2PostAuthenticationPlugin.

Set the Single Logout Enabled option to false in the SAML2 authentication module configuration.

Single logout occurs only when the user initiates logout at the service provider.

Not available.

Single logout never occurs.

Do not set the post-authentication processing class for the authentication chain that contains the SAML2 authentication module to org.forgerock.openam.authentication.modules.saml2.SAML2PostAuthenticationPlugin.