Knowledge comes from experience and continuous practical hands-on ...

Hands On Labs : Seamless SSO between applications protected by different Identity Provider (Salesforce and OpenAM) – IDP Chaining

Business Requirement

Your company use an on-premise Identity provider like OpenAM and want to migrate using a cloud solution identity provider like Salesforce, providing a central repository for your employee, customer and partner. New developed application can start using the new identity provider, and existing application authenticating against the legacy identity provider will not change during this transition phase. The challenge is to have a seamless Single Sign On between new and legacy applications.

Let’s describe the use case:

Scenario 1: Seamless access to two applications : Salesforce to OpenAM using SAML Federation / Salesforce as an IDP to OpenAM as SP
- User B want to access an Application B (with password B) using Salesforce acting as Identity Provider
- User A can access an Application A (with password A) using OpenAM, acting as Identity Provider
- User B want to access Application A, without entering any password – Credentials (login/password) don’t have to be the same.

Scenario 2: Seamless access to two applications : OpenAM to Salesforce using SAML Federation / OpenAM as IDP to Salesforce as SP
- User A want to access an Application A (with password A) using OpenAM acting as Identity Provider
- User B can access an Application B (with password B) using Salesforce, acting as Identity Provider
- User A want to access Application B, without entering any password – Credentials (login/password) don’t have to be the same.

SAML is a popular federated authentication method that provides web based single sign-on. One of the key security advantages to SAML is the reduction in username/password combinations that a user has remember. The identity provider is the SAML service that authenticates the user and passes an assertion to then service providers proving the user’s identity. Fortunately, most of the identity provider can also act as service provider. We will use this feature to achieve the described use case. If we take scenario 1 as an example, since Application B is configured to authenticate against the Salesforce we need to convert the Salesforce SAML assertion into a OpenAM SAML assertion (known as IdP chaining).

OpenAM and Salesforce support both federated authentication and can act as IdP and/or SP. The credentials (username & password) are validated on the IdP and the SP receives a SAML assertion in an HTTP POST request.

Enable Salesforce.com as an identity provider so you can use single sign-on with other web sites, and define the appropriate service providers whose applications support single sign-on. You can switch to different service providers without having to log in again.

Required Steps

I have already describe how to expose your openAM instance on the internet. This is a pre-requisite before doing any configuration in OpenAM.
Below the post of scenarios I have configured and tested. You will find the technicals details of the HTTP Request exchange.

I have fully tested the scenario1 & scenario 2.