Login via IDP uses previous session from other IDP-Config

1

Hi,
we have several configurations to different IDPs in our keycloak (Version 11). There are two IDPs configured which are both using Microsoft Azure as their IDP-Backend, but the Tenant differs. This two configs are used from different applications on our site. Our application has a SSO-Login button included on the Login-Site (so we do NOT use the Keycloak-Login site; the user does not realize that we use keycloak at all).
We initiate the IDP-Login with a call to this URL directly from the browser (kc_idp_hint is present):

https://my-keycloak.de/auth/realms/my-realm/protocol/openid-connect/auth?client_id={clientId}&response_type=code&kc_idp_hint={idp}

Now let’s assume the following scenario:

  1. A User opens our application A in a new browser tab. Application A has IDP X on its login-site as link available.
  2. The user clicks the SSO-Link, gets redirected to the IDP-Login-Form and returns to the application with a new session.
  3. The user then opens our application B in another browser tab. Application B has IDP Z on its login-site as link available.
  4. The user clicks the SSO-Link and gets immediately redirected back to the application without entering the Login-Form of IDP Z. The session from the IDP X is reused!

So Keycloak (or the IDP) reuses the session from a different IDP-Config within keycloak. I tried to turn the flag “Force Authentication” on for both IDP-Configs but this has no effect.

My questions:

  • Is the behaviour at all correct or intended?
  • Is it okay that “Force Authentication” has no effect? (Or is this flag for sth else, which is not clearly stated in the docs?)
  • Can this be fixed on Keycloak-site at all?
  • Can this be fixed on the IDP-site?

If someone needs more infos, do not hesitate to ask.
Thanks!

2

I would say this is expected ( you are logged in to the realm, the4 idp_hint is just hint, not a requirement).

Best solution would be to just use different Realms ( thats why they exist).

3

Yes, that‘s how SSO works, like @bpedersen2 already mentioned.

The config in the IdP has no effect, since (assuming you are using standard auth flows) the auth state recognition from the cookies is the first step in the flow. So, if a user is already authenticated, this is recognized from the cookies and the IdP step is never executed, mo matter if there is an idp_hint or not.

A possible solution might be to adjust and customize the auth flow with a custom authenticator step as the first one, before the the cookie step.

4

Thank you for your answers.

@bpedersen2 The problem with realms in our case is, that we have some internal “customers” which have to share the same user-base and -session. If we separate them to multiple realms this would not work. But we don’t want to have realm- and auth-structures which differ too much.

@dasniko Can you give an advise on how a custom authenticator step (or flow-config) might look like to achive this?

5

Use the CookieAuthenticator (Factory / Provider) as starter or extend it for you own custom cookie authenticator.
In the authenticate() method of the provider, implement/adjust the code in your desired way, that if there‘s a query parameter for the IdP, don‘t accept an available cookie and redirect the user to the IdP (see IdentityProviderAuthenticator/Factroy in the same package as the above mentioned), or just don‘t lead to success, so that the next authenticator will be accessed in your flow.

Copy the standard browser flow and replace the first step (default cookie authenticator) with you custom cookie authenticator you just created.

image
image1623×530 70.2 KB

Read more about SPIs here:
https://www.keycloak.org/docs/latest/server_development/index.html

Does this help?

6

Thanks for your detailed explanation!! I will try to implement this.