SSO and SLO in 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 console, create a hosted service provider by following the steps in "To 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 "To 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:

   1. In the AM console, go to Realms > Realm Name > Applications > Federation > Entity Providers > Service Provider Name > Services > Assertion Consumer Service.

   2. 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.

   3. 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.

   4. The results will resemble the following:

      
      
      

      Save your changes.

   Now you are ready to configure authentication trees.

When using integrated mode, the SP can leverage the authentication tree's features to tailor the authentication experience to the users. Therefore, 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 With SAML2 Authentication Node

1. Add a "SAML2 Authentication Node". Remember that integrated mode is SP SSO-initiated only, and that 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. See "Linking Identities by Using Authentication Trees or Chains".

When using integrated mode, the SP can leverage the authentication tree's features to tailor the authentication experience to the users. Therefore, 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

1. Add a "SAML2 Authentication Node". Remember that integrated mode is SP SSO-initiated only, and that 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 Functionality".

3. Add a "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 gathered 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. See "Linking Identities by Using Authentication Trees or Chains".

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

2. In the AM console of the SP, create a hosted service provider by following the steps in "To Create a Hosted Entity Provider".

3. Configure a remote identity provider by following the steps in "To 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:

   1. In the AM console, go to Realms > Realm Name > Applications > Federation > Entity Providers > Service Provider Name > Services > Assertion Consumer Service.

   2. 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.

   3. 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.

   4. The results will resemble the following:

      
      
      

      Save your changes.

5. Create a SAML2 authentication module:

   1. In the AM console, go to Realms > Realm Name > Authentication > Modules, and then select Add Module.

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

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

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

   4. 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 Federating Identities.