7.3 Example Scenarios

7.3.1 Scenario 1: Cloud-based IDP and On-Premises SP with a Protected Resource

In this scenario, the cloud-based setup is configured as the IDP and the on-premises setup is configured as the SP. The SP setup has Access Gateway protected resources.

The protected resources need to be accessed from appmarks displayed in the user portal page of the cloud-based setup.

User Flow
  1. A user browses to the URL of the cloud-based user portal page and specifies the credentials.

    The user sees the expected appmarks including the appmark for the Access Gateway protected resource at the on-premises SP.

  2. The user clicks the appmark for the protected resource. The user is authenticated to the on-premises SP using the SAML protocol.

    After a successful SAML authentication, the user sees the expected content of the protected resource.

Configuration Details
  1. Establish the federation between the two setups by importing and configuring the Access Manager SAML connector at the cloud-based setup to create the SAML application.

  2. Follow the federation instructions provided by SAML application to complete the federation at the on-premises setup.

    With this configuration, the cloud-based Access Manager setup acts as an IDP while the on-premises Access Manager setup acts as an SP.

  3. At the on-premises setup, configure an Access Gateway protected resource with Authentication Procedure set to Any Contract.

  4. At the cloud-based setup, use the Applications page to create an appmark for the Access Manager SAML application and configure URL (Target override) with the public URL of the Access Gateway protected resource at the on-premises setup.

7.3.2 Scenario 2: On-Premises IDP and Cloud-based SP with a Protected Resource

In this scenario, the on-premises setup is configured as the IDP and the cloud-based setup is configured as the SP. The SP setup has Access Gateway protected resources.

The protected resources need to be accessed from appmarks displayed in the user portal page of the on-premises setup.

User Flow
  1. A user browses to the URL of the on-premises user portal page and specifies the credentials.

    The user sees the expected appmarks including the appmark for the Access Gateway protected resource at the cloud-based SP.

  2. The user clicks the appmark for the protected resource. The user is authenticated to the cloud-based SP the SAML protocol.

    After a successful SAML authentication, the user sees the expected content of the protected resource.

Configuration Details
  1. Establish the federation between the on-premises and cloud-based setups by importing and configuring the Access Manager SAML connector at the on-premises setup to create the SAML application

  2. Follow the federation instructions provided by the SAML application to complete the federation at the cloud-based setup.

    With this configuration, the on-premises Access Manager acts as an IDP and the cloud-based Access Manager acts as an SP.

  3. At the cloud-based setup, configure an Access Gateway protected resource with Authentication Procedure set to Any Contract.

  4. At the on-premises setup, use the Applications page to create an appmark for the Access Manager SAML application and configure URL (Target override) with the public URL of the Access Gateway protected resource at the cloud-based setup.

7.3.3 Scenario 3: On-Premises IDP and Cloud-based SP with Third-party SP

This scenario builds upon Scenario 2: On-Premises IDP and Cloud-based SP with a Protected Resource by adding additional configuration required for SSO to third-party SAML SPs, such as Salesforce, Google, and Office 365. These service providers are configured and trusted by the cloud-based Access Manager setup.

This scenario enables SSO to the cloud-based user portal page and third-party SPs when the users log in to the on-premises setup.

User Flow
  1. A user browses to the URL of the on-premises Access Manager IDP user portal page and specifies credentials.

    The user sees the expected appmarks including the new appmark for the user portal page at the cloud-based Access Manager setup.

  2. The user clicks the appmark for the user portal page at the cloud-based setup.

    The user is authenticated to the cloud-based SP using the SAML protocol.

    After a successful SAML authentication, the user sees the user portal page of the cloud-based setup.

  3. The user clicks the appmark for the third-party SP.

    After a successful SAML authentication, the user sees the expected content of the SP.

Configuration Details
  1. Establish the federation between the two Access Manager setups and verify as described in Scenario 2: On-Premises IDP and Cloud-based SP with a Protected Resource.

  2. Configure the on-premises setup as follows:

    1. In the Applications UI, modify the Access Manager application and add an additional appmark.

    2. In URL (Target override), specify the URL of the user portal page of the cloud-based Access Manager setup.

    3. Modify the attribute set originally created and used by the Access Manager SAML application in Administration Console > Shared Settings.

      By default, the mappings for sn and givenName are created. Add the additional attribute mappings as follows:

      Local Attribute

      Remote Attribute

      Ldap Attribute: cn

      cn

      Ldap Attribute: GUID

      GUID

      Ldap Attribute: mail

      mail

    4. In the Applications page for the Access Manager connector, select Send with for all attributes in the Attributes section.

  3. Configure the cloud-based setup as follows:

    1. Verify that the SAML 2.0 federations have been configured with third-party SPs, such as Salesforce, Google, and Office 365. After logging in to the user portal page of the cloud-based setup, users see appmarks associated with each provider. Users are single signed-on to these providers when clicking the respective appmarks.

    2. Modify the attribute set originally created when following federation instructions to create the IDP object in Administration Console > Shared Settings.

      By default, the mappings for sn and givenName are created. Add the additional attribute mappings as follows:

      Local Attribute

      Remote Attribute

      Ldap Attribute: cn

      cn

      Ldap Attribute: objectGUID

      GUID

      Ldap Attribute: mail

      mail

    3. Go to Devices > Identity Server > Edit > SAML 2.0 > [IDP] > Configuration > Attributes. Modify the IDP object and move all attributes to the Obtain at authentication field. All these attributes will be obtained during authentication.

If the Office 365 SAML application is configured at the cloud-based setup, ensure that the SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME property is configured for the Office 365 SP. Else, SSO may fail for users being federated from the on-premises setup.

Configuring SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

  1. In the cloud-based Administration Console, click Devices > Identity Servers > cluster > Edit > SAML 2.0 > [Office 365 SP] > Configuration > Options.

  2. Click New.

  3. Select Other from the list.

  4. Specify the following values:

    Property Name: SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME

    Property Value: objectGUID

  5. Click OK.

  6. Update the Identity Server cluster.

7.3.4 Scenario 4: On-Premises IDP, Cloud-based SP with Third-party SP, and Third-party SP Is Accessible from On-Premises User Portal

This scenario builds upon Scenario 3: On-Premises IDP and Cloud-based SP with Third-party SP by adding appmarks for each third-party service provider (Salesforce, Google, and Office 365) on the user portal page of the on-premises setup. With this configuration, users can access these service providers without navigating to the user portal page of the cloud-based Access Manager setup.

In addition to the configurations made in the scenario 3, you need to add appmarks on the Access Manager SAML application at the on-premises setup.

User Flow
  1. A user browses to the URL of the on-premises Access Manager IDP user portal page and specifies credentials.

    The user sees the expected appmarks including the new appmarks for each third-party SP configured in the cloud-based Access Manager setup.

  2. The user clicks any of the appmarks for the third-party SP.

    After a successful SAML authentication to the cloud-based Access Manager setup, the user is single signed-on to the third-party SP and redirected to the appropriate destination.

Configuration Details
  1. Follow the steps for configuring Scenario 3: On-Premises IDP and Cloud-based SP with Third-party SP. See Configuration Details.

  2. Configure additional appmarks on the Access Manager SAML application at the on-premises setup (one for each third-party SAML SP configured in the cloud-based setup).

    1. In the Applications page of the on-premises setup, open the Access Manager SAML application for editing.

    2. In the Appmarks region, click + to add an additional appmark.

    3. Specify an appropriate value for Name and other settings as desired.

    4. In URL (Target Override), specify the URL of the appmark at the cloud-based setup.

      You can copy this URL from the appmark editor for the third-party application, under URL used by Appmark on User Portal at the cloud-based setup.

      A typical configuration of a Google application contains an appmark with a URL that includes scheme, Identity Server Base URL, PID, and an optional Target.

      The following are examples for Salesforce, Google, and Office 365 configuration:

      Salesforce: https://idp.baseurl.cloud:8443/nidp/saml2/idpsend?PID=TSP_3bdb77e5-9515-4f2d-9699-86c0a48fba2c

      Google: https://idp.baseurl.cloud:8443/nidp/saml2/idpsend?PID=TSP_59d317d4-85cb-407a-9d39-431a88ad164a&target=https://mail.google.com/a/cloudtest13.info

      Office 365: https://idp.baseurl.cloud:8443/nidp/saml2/idpsend?PID=TSP_975bf51a-91b8-4a35-ab48-5aad5cdc8510

  3. Repeat the step 2 for each third-party SAML application for which you want to create an appmark at the on-premises setup.

NOTE:If the Office 365 SAML application is configured at the cloud-based setup, ensure that the SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME property is configured for the Office 365 SP. Else, SSO may fail for users being federated from the on-premises setup.

For information about how to configure this property for the Office 365 SP, see Configuring SAML2_OFFICE365_NAMEID_ATTRIBUTE_NAME.