Single sign on accross multiple client ID

Setup
, ,
#1

Hi experts,

We are on Forgerock 7.3 version now.
There are 2 types of authentication flows that we are doing , SAML & OIDC.

We are exploring the idea of single sign on and would like to check on the guidance of setting this up.

For example we have a set of clientID

  1. ClientID-A (APPLICATION A)
  2. ClientID-B (APPLICATION B)
  3. ClientID-C (APPLICATION C)

What we are trying to achieve is, if user has been authenticated by ClientID-A, when he tried to login for APPLICATIONB(CLIENTID-B), he wont be prompted to authenticate again.

Is there a way we can group a set of ClientID such that if user has been authenticated by any of the clientID in the group, user will not be required to authenticate to the rest of the ClientID in the group?

For your kind assistance please,

Thank you

1 Like
#2

Hi all, bumping this up for help please.

Thank you

#3

Hi @mikechng,

For both cases SAML and OIDC what matters is a central IDP - e.g ForgeRock AM. In the SAML2 context, all external portals (e.g apps) - so all acting as SPs - are in the AM’s IDP’s circle of trust. They all go thru the same authentication endpoint, so once a user is authenticated with one app, the user is authenticated for all apps.

In the OIDC case, the principle is the same, for all Apps (e.g “client IDs”) the user authenticates against AM to obtain the session necessary to initiate the OAuth2 flow - id_token is produced - consumed by the client - validated and eventually a local session (so local to the App) can be produced based on the id_token assertion trust (so this is the social provider authentication model) or only the access token is consumed for app authorisation (in which case the app is to interact with ForgeRock to validate the access token before allowing resource access). In this model, the user agent holds the AM authentication session (which is checked against the AM endpoint), all apps, if they have not yet obtained an access token (or does not have the id_token or local generated session) have to go thru the OAuth2 flow.

I hope this helps,

Regards
Patrick

1 Like
#4

Hi Patrick,

Thank you so much for your response.
For our case currently, for a different clientID (OIDC) or different EntityID (SAML), the users have to re-authenticate. Do you think this has something to do with our Authentication trees?

Best Regards,
Mike

#5

Hi @mikechng,

These are two possible reasons for this issue:

  • The user agent is not propagating the session cookie to AM. This happens when the AM authenticate endpoint is invoked on a different domain as the previously delivered session cookie for the other app. To fix this, make sure all apps are using the same domain - or use a sub-domain of a common domain - and ensure this cookie domain is configured in the AM realm.

  • The Apps are authenticating against different realms. Unfortunately, SSO is supported only within a realm, a user has to re-authenticate when changing realm.

I hope this helps

Regards
Patrick

1 Like