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.
TwoSeparate_IDPs_2016-03-26_14-10-36

IDPs_Challenge_2016-03-26_14-11-08

Transition_Period_2016-03-26_14-11-36

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.

SAML SSO - IDP Chaining- Salesforce to OpenAM

 

  • 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 SSO - IDP Chaining- OpenAM to Salesforce

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.

The configuration in OpenAM

Below the screenshot of my OpenAM instance configuration. I have some a lot of trials to have this working properly

The federation tab

Federation_Tab_2016-04-02_17-11-15The Circle Of trust tab

cot_tab_2016-04-02_17-13-43

Entity Provider

SP – Assertion Content

SP_AssertionContent_2016-04-02_17-16-39

SP – Assertion Processing

SP_Assertion_Processing_2016-04-02_17-18-11

SP – Service

SP Service - 2016-04-02_17-19-46

SP – Advanced

SP Advanced - 2016-04-02_17-20-51

OpenAM IDP Settings

IDP Assertion Content

IDP Assertion Content - 2016-04-02_17-22-39

IDP – Assertion processing

IDP Assertion Processing - 2016-04-02_17-24-02

IDP – Services

IDP Services - 2016-04-02_17-24-53

IDP Advanced

IDP Advanced - 2016-04-02_17-25-58

Entity Provider Salesforce Configuration

SP Assertion Content

SP Assertion Content - 2016-04-02_17-28-21SP Assertion Processing

SP Assertion Processing - 2016-04-02_17-29-08

SP Services

SP Services - 2016-04-02_17-30-21

SP Advanced

SP Advanced - 2016-04-02_17-31-13IDP Assertion Content

IDP Assertion Content - 2016-04-02_17-33-08IDP Assertion Processing

IDP Assertion Processing - 2016-04-02_17-34-18IDP Services

IDP Services - 2016-04-02_17-35-15IDP Advanced

IDP Advanced - 2016-04-02_17-35-55

 

Local Site Properties – SAML 1.1

Local Site Properties - 2016-04-02_17-37-57

 

 

 

 

The configuration in Salesforce

Salesforce as Identity Provider

SFDC Identity Provider - 2016-04-02_17-40-58

OpenAM as Service Provider – Single Sign On Setting

SFDC SSO Setting - 2016-04-02_17-41-58

Connected App to OpenAM12 as SP

Connected App - OpenAM as SP - 2016-04-02_17-46-30

 

Connected App to SAML Heroku Apps

Connected App - Heroku - 2016-04-02_17-45-19

Connected App to Salesforce as Service Provider

SFDC as SP connected App_2016-04-02_17-44-21

 

How my tests user are linked:

Demo Users - 2016-04-02_17-51-19

Thanks for reading.

Advertisements