4 ms·

Realms are not necessarily equivalent to tenants in Keycloak. You can run many tenants inside a single realm (we do). They can all log in to their account usin

by beachy 4y ago

Realms are not necessarily equivalent to tenants in Keycloak. You can run many tenants inside a single realm (we do). They can all log in to their account using Google, LI, etc., as well as email/password. It's only if your tenant requires SSO, e.g. to their corporate idp, that their own realm is required. Of course you may choose architecturally to put every tenant in their own realm but that is overkill IMO.

mooreds 4y ago
Ah, thanks. It probably depends on what you mean by tenant; there's no real accepted definition. By tenant, I mean a separate user space, and I think that is analogous to Keycloak realms. (So dan@example.com in tenant 1 has no connection at all with dan@example.com in tenant 2; separate passwords, different profile data, etc.) But it sure looks like you can have multiple tenants (in your SaaS application) all against one realm in Keycloak if you don't want that level of separation. In fact, here's an article from 2020 discussing that exact architecture: https://medium.com/swlh/using-keycloak-for-multi-tenancy-with-one-realm-7be81583ed7b https://medium.com/swlh/using-keycloak-for-multi-tenancy-wit...
- beachy 4y ago
  Separate user spaces are achievable within a single realm. In our case, we do it using an account chooser within our application code. After logging in, you select the account you want to work within. I think of realms as part of a trust model. No realm can safely "trust" another realm's user identities. For example, if I own my own realm, I can set up my own bogus idp and pretend to be the user president@whitehouse.gov, even though I don't own that email or have any access to it. In our case, the exception is the central realm, where all customers who don't need SSO live. In SaaS, this is usually most customers (> 90% for us). Only larger and more security-minded orgs will want their own SSO and hence their own realm. In the central realm, anyone can authenticate through a set of "trusted" idps (Facebook, Google etc.) as well as good old email and password. This does make the central realm vulnerable to compromise of e.g. Facebook.

by beachy 4y ago

mooreds 4y ago

Ah, thanks. It probably depends on what you mean by tenant; there's no real accepted definition. By tenant, I mean a separate user space, and I think that is analogous to Keycloak realms. (So dan@example.com in tenant 1 has no connection at all with dan@example.com in tenant 2; separate passwords, different profile data, etc.) But it sure looks like you can have multiple tenants (in your SaaS application) all against one realm in Keycloak if you don't want that level of separation. In fact, here's an article from 2020 discussing that exact architecture: https://medium.com/swlh/using-keycloak-for-multi-tenancy-with-one-realm-7be81583ed7b https://medium.com/swlh/using-keycloak-for-multi-tenancy-wit...

beachy 4y ago
Separate user spaces are achievable within a single realm. In our case, we do it using an account chooser within our application code. After logging in, you select the account you want to work within. I think of realms as part of a trust model. No realm can safely "trust" another realm's user identities. For example, if I own my own realm, I can set up my own bogus idp and pretend to be the user president@whitehouse.gov, even though I don't own that email or have any access to it. In our case, the exception is the central realm, where all customers who don't need SSO live. In SaaS, this is usually most customers (> 90% for us). Only larger and more security-minded orgs will want their own SSO and hence their own realm. In the central realm, anyone can authenticate through a set of "trusted" idps (Facebook, Google etc.) as well as good old email and password. This does make the central realm vulnerable to compromise of e.g. Facebook.