User to multiple tenant/realms in keycloak

[Anuj Aneja]

Hi Everyone,

We are a SAAS based organization where we have a use case that one user can have access to multiple tenants/realms, how can we implement this in Keycloak. As per my understanding, the user is created per realm only?

Thanks & Regards,

Anuj Aneja

[Garth]

This is a question that gets asked often on this list. No exact right answer, but you might search on the list to find threads like this:
https://groups.google.com/g/keycloak-user/c/CfjjMEJRjtE/m/7RmGUmHCBwAJ

https://keycloak.discourse.group/t/architecture-ideas-on-multi-tenancy-at-customer-permisses/1807

https://keycloak.discourse.group/t/keycloak-for-an-enterprise-saas/4402

Regarding your question, yes, a user is created per realm.

> --
> You received this message because you are subscribed to the Google
> Groups "Keycloak User" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to keycloak-use...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/keycloak-user/d80ef820-0b81-4520-a6a8-555edf06d6f5n%40googlegroups.com <https://groups.google.com/d/msgid/keycloak-user/d80ef820-0b81-4520-a6a8-555edf06d6f5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Thomas Darimont]

Hello Anuj,

I usually tackle those use-cases with cross-realm identity brokering.

# Cross-Realm Identity Brokering
You might have all your internal users and internal clients in a realm like "acme-internal" if you are the acme company.

Perhaps you have some realms for customers like "acme-customers-1", "acme-customers-2", ... "acme-customers-N" where all users and clients of this particular customer reside.

You can now register an Identity Provider (Keycloak OIDC) in every "acme-customer-*" realm that points to the "acme-internal" realm.
For the Identity Provider in a customer realm, you also need a (confidential) OIDC target client in the "acme-internal" realm. For this, you can either use the generic "broker" client or create one or more dedicated confidential clients, e.g., one per "acme-customer-*" realm. I usually do the latter.

This setup allows users from the "acme-internal" realm to sign in to the "acme-customer-*" realms where the identity provider is configured.

When a user logs in via identity brokering, Keycloak will dynamically generate brokered user accounts for "acme-internal" users in the respective target "acme-customer-*" realm. Those users don't have a password and can (by default) only log in through the identity provider. Otherwise, those users are normal Keycloak users; you can assign roles to them, manage attributes, join groups, etc.
Note that the realms you connect via identity provider don't have to live in the same Keycloak system! Those realms could, in fact, come from completely different Keycloak systems, potentially running with different versions and use different authentication flows.

# Cross-Realm Identity Brokering and Global Apps Realm
In an extension of this model, you could also have a realm like
"acme-apps" where all the "acme-internal" and "acme-customer-*" realms are registered as Keycloak OIDC identity providers. This "acme-apps" realm can then provide clients, which can potentially be used by all users across all the realms.

# Cross-Realm Identity Brokering with LDAP Federation
This model is very flexible and can even be combined with an LDAP-based user federation. In this case, LDAP defines which users are present in a particular realm and what attributes and group membership they have but without providing any way to log in. The login is only possible through the identity provider and only for those users who are indeed listed in the particular LDAP federation.

Cheers,
Thomas

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/df072a5e-ca41-42b4-bbb7-1eaac3960b86%40www.fastmail.com.

[Anuj Aneja]

Thanks, Thomas for your prompt response,

I tried your suggested solution "# Cross-Realm Identity Brokering" and to implement this i created:

•  Realm named "uniware_web" (same as  "acme-customers-1") 
•  "uniware_internal" and
•  Also "uniware_client" in realm(uniware_internal).  (Registered as Keycloak OPENID CONNECT Identity Provider)

I am able to see the login page with the option to log in to "UNIWARE INTERNAL" and after login, i am redirected back to "uniware_web" realm. But, I have following questions:

1.  Now, I can create one internal realm and multiple internal clients linked to different relams like "uniware-web-*". 

2. But, in our current flow, we want that as soon as a user is logged in he/she should be able to show the list of tenants/realms it belongs to and upon selecting the tenant user should be logged into the particular relam/tenant. How can we implement the same using keycloak? 

Thanks & Regards,

Anuj Aneja

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/CAK-7U1gY9c-vDHW%3DfeFmmdSKnJ04pdR-c1uT%2BtqqOkFY39R3Jw%40mail.gmail.com.

[Anuj Aneja]

Hello Everyone,

Using multiple realms might not solve the problem for us because we have more than 4k tenants and So, would like to go for the single realm,  group as tenant approach.

org_relam

          user1-> tenant1_grp1

          user2 -> tenant2_grp2

          user3 -> tenant2_grp2

          user4 -> tenant1_grp1

So, here a user can belong to multiple tenants i.e. groups. So, is there a way in Keycloak itself to show the intermediate screen to user after login based on the groups/tenants it belongs to? or do we need to create our own middleware application to do the job?

Regards,

Anuj Aneja  

[Rohit Patidar]

Hey Anuj,

Did you found solution to your requirement?

Thanks,

Rohit

[Anuj Aneja]

Hi Rohit,

We handled this by doing the following things:

1.  We used our existing Auth server as a proxy where we show the list of accounts/tenants it belongs to after login. (Keycloak adapter is used here)

2. Inside Keycloak we created a single realm and auth_proxy clients which points to the above-mentioned application. 

3. User -> tenants information is stored in groups. (Here groups represents the tenants which are sent into the token using mappers)

I hope this helps.

You received this message because you are subscribed to a topic in the Google Groups "Keycloak User" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/keycloak-user/grVY_eq2j6s/unsubscribe.
To unsubscribe from this group and all its topics, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/69e19099-6c21-4fcb-a60e-73690f19b1f9n%40googlegroups.com.

[Rohit Patidar]

Thanks Anuj for your reply.

I'm bit new to keycloak so didn't understood you fully. How you stored information in groups (as mappers are on client level). Please could you elaborate a bit.

What I was trying to do something but stuck at below point :

https://groups.google.com/g/keycloak-user/c/llPC3xFRSp4

Thanks a lot.

Rohit

[Ana Mattuzzi]

Hi Anuj, 

I hope that you receive this message. We need to implement a solution similar to yours, where the user can be assigned to several tenants that we model with groups. On login the user needs to select the tenant from the tenants that we fetch from the JWT token, and continue with login to the chosen tenant. 

After tenant selection JWT token should contain the roles just for the chosen tenant, so we could fetch the RPT token with the assigned permissions.

As we're new to keycloak we don't understand what you meant by existing auth server that acts as a proxy. Did you use the https://hub.docker.com/r/8gears/keycloak-auth-proxy? Or did you implement it yourselves? If so, could you, please, describe your solution in more detail. Maybe add some code snippets or screenshot so I could follow your solution better.

Thanks in advance,

Ana