Multi tenancy

[Johan Sandqvist]

Hello cloakers,

We are in the process of defining the architecture of a multi tenant SaaS product and considering Keycloak with PostgreSQL within that.
Each tenant in our product need to be able to have its own SSO configuration so a Realm per Customer (tenant) seems like the necessary approach.

Has anyone used Keycloak in a multi tenancy SaaS application and know any limitations in number of Reals it supports or any other limitations with a setup like that?

/Johan

[Eugen Stan]

Keycloak did not handle many realms very well (500+).

I don't know what the status on that is.

In our use-case, we implemented multi tenancy in our application and
used a single keycloak realm to store all our users.

We use keycloak as an identity store and oidc provider - so no realm
admin delegation to users etc.

We also don't use keycloak roles or groups or authz services.

It was better for us to do that on the service layer.

I hope it helps.

Eugen

> --
> 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
> <mailto:keycloak-use...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/keycloak-user/b6275c7a-44e6-4ed9-99e6-630b636817e2%40googlegroups.com
> <https://groups.google.com/d/msgid/keycloak-user/b6275c7a-44e6-4ed9-99e6-630b636817e2%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johan Sandqvist]

Hi Eugen,

Did you have a need to provide SSO for the individual tenants and if so you I assume you found a way to do that within one Realm?

We would mostly look at Keycloak to handle storing user credentials, JWT token generation and the authentication and SSO functionality and would wrap admin functions like creating a new customer (tenant), new users and SSO/user federation config behind a service that use the admin api to facilitate. We would store minimal customer and user info in Keycloak and keep most of it in our service.

/Johan

[Eugen Stan]

Hi Johan,

La 02.04.2020 17:41, Johan Sandqvist a scris:
> Hi Eugen,
>
> Did you have a need to provide SSO for the individual tenants and if
> so you I assume you found a way to do that within one Realm?

Not sure what you mean by SSO for individual tenants. We use one realm.
We have implemented groups, roles, permissions in our app, not in keycloak.

We might use the roles in keycloak as well as our own permission system
but for other stuff like mark a user as a beta-tester etc.

We give users access only to the login, registration and account
applications. We keep admin access for ourselves. We don't delegate
access to users.

> We would mostly look at Keycloak to handle storing user credentials,
> JWT token generation and the authentication and SSO functionality and
> would wrap admin functions like creating a new customer (tenant), new
> users and SSO/user federation config behind a service that use the
> admin api to facilitate. We would store minimal customer and user info
> in Keycloak and keep most of it in our service.

I think we have a similar solution but we did not use a tenant /
customer. This means we can't delegate user administration to Keycloak
admin and we will have to implement it ourselves. This is not that bad
since we do have custom flows and rules. It also keeps our dependency on
Keycloak minimal.

As a side effect, since we have a single user store, a user can access
multiple tenants without requiring to register for multiple realms. For
us and the business model we have this is a very nice/important feature.

If keycloak model / UI changes we are not that impacted.

Good luck and please share your experience with this model once you go
live and face Day 2 operations.

I'm happy to have a call to share some of our experiences. Just let me
know.

Eugen

>
> /Johan
>
> On Thursday, April 2, 2020 at 1:26:15 PM UTC+2, Johan Sandqvist wrote:
>
> Hello cloakers,
>
> We are in the process of defining the architecture of a multi
> tenant SaaS product and considering Keycloak with PostgreSQL
> within that.
> Each tenant in our product need to be able to have its own SSO
> configuration so a Realm per Customer (tenant) seems like the
> necessary approach.
>
> Has anyone used Keycloak in a multi tenancy SaaS application and
> know any limitations in number of Reals it supports or any other
> limitations with a setup like that?
>
> /Johan
>

> --
> 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
> <mailto:keycloak-use...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/keycloak-user/03939f4f-9940-4f9d-8cda-40f3fb02ab52%40googlegroups.com
> <https://groups.google.com/d/msgid/keycloak-user/03939f4f-9940-4f9d-8cda-40f3fb02ab52%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Johan Sandqvist]

With SSO I mean that each tenant (usually larger enterprises) could use their own IdP and Keycloak can facilitate SAML or OIDC interaction with a specific customer IdP and enable us to provide Single Sign-On for the users from that customer. It could even support google authentication etc of a customer was using that but it has to be configured per Realm and that is what is forcing the multiple realms approach for us.

[Seth Foss]

Let me see if I can help put this in more technical Keycloak terms. 

You have multiple tenants/customers on the application side, each with a group of users. You are concerned about the scalability of setting up one realm per tenant, but you would also like each tenant to have a unique set of Identity Providers, so it seems like one realm per tenant is necessary.

My own experience: We just started adding support for Identity Providers (SSO) to our application. I don't see any way to have these varied within a common realm. I think you're correct that the Identity Providers are going to force you towards multiple realms.

[Eugen Stan]

Hi Johan, Seth,

Now I understand. We don't use IdentityProviders yet and I did not think
about that much for now since it's going to be 1y+ until we get there
(estimate).

We will see how Keycloak is when we get there.

Thank you for the feedback Seth. I will look into this at some point.

I would appreciate if you could be more specific as to why you made this
statement:

"I think you're correct that the Identity Providers are going to force
you towards multiple realms."

I have a hunch that we might be able to manage multiple identity
providers for different tenants in the same realm. However that means we
will have to handle that registration for the users or provide them with
a custom UI to hide the other providers from them - re-implementing the
the Keycloak IdentityProvider UI ( the wheel, a bit less round. :D )

Regards,

La 03.04.2020 14:39, Seth Foss a scris:
> Let me see if I can help put this in more technical Keycloak terms. 
>
> You have multiple tenants/customers on the application side, each with
> a group of users. You are concerned about the scalability of setting
> up one realm per tenant, but you would also like each tenant to have a

> unique set of *Identity Providers*, so it seems like one realm per

> tenant is necessary.
>
> My own experience: We just started adding support for Identity
> Providers (SSO) to our application. I don't see any way to have these
> varied within a common realm. I think you're correct that the Identity
> Providers are going to force you towards multiple realms.
>
> On Friday, April 3, 2020 at 5:03:17 AM UTC-4, Johan Sandqvist wrote:
>
> With SSO I mean that each tenant (usually larger enterprises)
> could use their own IdP and Keycloak can facilitate SAML or OIDC
> interaction with a specific customer IdP and enable us to provide
> Single Sign-On for the users from that customer. It could even
> support google authentication etc of a customer was using that but
> it has to be configured per Realm and that is what is forcing the
> multiple realms approach for us.
>

> --
> 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
> <mailto:keycloak-use...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/keycloak-user/578f92d1-6001-41f3-81e9-7544673fc474%40googlegroups.com
> <https://groups.google.com/d/msgid/keycloak-user/578f92d1-6001-41f3-81e9-7544673fc474%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Seth Foss]

You can certainly have all the IDPs for the various tenants in the same realm.

With the built-in UI, all of then IDPs would be presented to users at the login page. We've done very little with Keycloak customization besides basic theming - I have no concept of what you may be able to achieve by writing your own Identity Provider UI. That may be a viable solution. The most obvious problem that needs solved there is how to tell which tenant a user belongs to before they've logged in (if all tenants live in one realm).

[Eugen Stan]

Hi,

Thanks for replying.

La 06.04.2020 14:42, Seth Foss a scris:
> You can certainly have all the IDPs for the various tenants in the
> same realm.
>
> With the built-in UI, all of then IDPs would be presented to users at
> the login page. We've done very little with Keycloak customization
> besides basic theming - I have no concept of what you may be able to
> achieve by writing your own Identity Provider UI. That may be a viable
> solution. The most obvious problem that needs solved there is how to
> tell which tenant a user belongs to before they've logged in (if all
> tenants live in one realm).

The question that I would like to ask is (to spark discussion) : Besides
a custom Identity Provider, why do I need to know the realm before login?

For the custom Identity Provider provider, I agree - you don't want to
display all of them. This can be solved from the login screen by asking
for the email first and then for the password, after a search in the
back-end. I've seen this done by Microsoft for example.

Another option would be like Amazone AWS - to ask for a tenant id
alongside user and password.

Of course this presumes we customize our login screen.

Regards,

Eugen