Hello,
we have different Subsystems and thought that it would be a good idea to set up a broker per subsystem. But then we found out that Keycloak SSO (login once and jump to another frontend without reentering credentials) is only possible if all clients/frontends are configured in the same realm.
I am very interested to know what the reasons are for the current implementation. Is it a missing feature or is this a security feature that the SSO is only allowed for clients of one realm?
Does someone know where I can find more informations about that? E.g. a specification how to implement that cross-realm SSO and how to extend Keycloak? Or a Specification that describes why it is not allowed to do that?
That depends on the realm defition, see doc and you will find:
A realm manages a set of users, credentials, roles, and groups. A user belongs to and logs into a realm. Realms are isolated from one another and can only manage and authenticate the users that they control.
Hello,
thanks for the answer. I know that it is currently not possible and I have understood Keycloaks realm concept. And we plan to build up a System with an Identity Provider and one or multiple Brokers. There it is for example possible to link users and build a relationship between 2 realms - one in the IP and one in the Broker. Thatâs why I am asking myself - if this is possible, why is the cross-realm not possible?
My question is, why is it not possible. Is it a feature that Keycloak has not implemented? Or does it contradict a security requirement? Or is there another reason?
Is anyone aware of a specification on how to safely implement a cross-realm SSO based on OpenID Connect/OAuth2 - similar to the Identity Brokering implementation? For example, in the WS-Federation specification I have seen many flows, but no SS-On.
Weâd also be interested if it would be possible to overcome the realm isolation with âcross realmâ identity brokering with regards to SSO (and also Single Sign-Out). Has anyone tested this successfully?
We provide SSO from a users perspective with identity brokering and token exchange. So if a user logged in to an app in realm A wants to âjumpâ to an app in realm B, they click a link in app A which passes an access token to app B which exchanges it for an access token of realm B and the user is logged in to app B with the exchanged token.
I donât think it was achieved in the traditional definition of âSSOâ. Users still would not be able to transfer sessions between realms (realms are isolated from each other). My guess is the poster allowed cross-realm access, however requiring re-authentication (if using same federated identity provider for both realms, can provide an illusion of SSO as the identity provider may have maintained sessions).
Sorry for the late reply.
For example, to allow users from application B in realm B to log in to application A in realm A, we set up an identity provider in realm A for realm B. Now, an app B user logged in to app A can open app B without having to log in to app B, because they have identity and session cookies for both apps. Which is obvious, because the user actually logged in to app B and was brokered to app A.
Of course, a user logging in to app B cannot just go to app A without logging in, and a user logged in to app A cannot go to app B without logging in there either.
So it is true, it is not like SSO between apps connected to the same realm, but if you can pick one app as the âleadingâ system, you can get SSO in the respective direction with identity brokering.
I missed to mention that in my example, app A lives in realm A and app B in realm B.
I only tried in one direction, with an IdP in realm A for B, allowing users from B to log in to A, just like this site lets me log in as GitHub user. If I am already logged in to GitHub, I can go here without having to log in (again).
I didnât try âcross realm identity brokeringâ and I wonder what happens if a user is imported/updated back and forth from one realm to another, maybe an error like âuser already existsâ occurs.