We are considering using Keycloack in a multi-tenant fashion. Each of our customer's account has its own users, and applications installed, and we also provide services API's consumed by various clients. We will have a large number of tenants. I found an open issue from 2017 that mentions that Keycloak may have some scalability issues with a large number of realms. https://issues.jboss.org/browse/KEYCLOAK-4593 And also this thread from 2016, https://lists.jboss.org/pipermail/keycloak-user/2016-October/008033.html, that states that "Keycloak was not designed to support multi-tenancy directly."..."In that regards we have never tested with high amounts of realms as we expect there to be few realms (up to 10 most likely)." I was wonder if there was any progress on the multi-tenancy use case, and are there any best practices on how to setup Keycloack to support it. On the other hand, is there any other approach to handle our use-case? Thanks, Litom

For your interest. We've evaluated internally the usage of many realms for customers and we've encountered many issues, both on the frontend application (admin console loading was really slow with 150-200 realms) and on the backend (in the code there are places where it iterates between realms, loading a lot of stuff). The cache helps, but i think that, for supporting multirealms, there should be some refactoring / redesign of some components. In addition, i think that some features like the sharing of a client between realms (think of many tenants accessing the same single page application, with the same client) need to be added.

The segregation of realms is a really cool feature, but could cause problems in a multi realm scenario (maybe introducing, also, some hierarchical relationships between realms could be useful). Have a nice day, Matteo On Tue, Sep 24, 2019 at 2:45 PM Marek Posolda <mposolda(a)redhat.com <mailto:mposolda@redhat.com>> wrote: Hi, there is no change in this area. Big number of realms can be still an issue. We plan some refactoring of the storage layer in near future (1-2 years as very rough estimate) and that should help to address the multitenancy use-case among other things. Marek On 23. 09. 19 9:14, Litom Segal wrote: > We are considering using Keycloack in a multi-tenant fashion. > Each of our customer's account has its own users, and applications > installed, and we also provide services API's consumed by various clients. > We will have a large number of tenants. > I found an open issue from 2017 that mentions that Keycloak may have some > scalability issues with a large number of realms. > https://issues.jboss.org/browse/KEYCLOAK-4593 > > And also this thread  from 2016, > https://lists.jboss.org/pipermail/keycloak-user/2016-October/008033.html, > that states that "Keycloak was not designed to support multi-tenancy > directly."..."In that regards we have never tested with high amounts of > realms as we expect there to be few realms (up to 10 most likely)." > > I was wonder if there was any progress on the multi-tenancy use case, and > are there any best practices on how to setup Keycloack to support it. > > On the other hand, is there any other approach to handle our use-case? > Thanks, > Litom > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user Like <https://www.facebook.com/cuebiq/>IFollow <https://twitter.com/Cuebiq>IConnect <https://www.linkedin.com/company/cuebiq> This email is reserved exclusively for sending and receiving messages inherent working activities, and is not intended nor authorized for personal use. Therefore, any outgoing messages or incoming response messages will be treated as company messages and will be subject to the corporate IT policy and may possibly to be read by persons other than by the subscriber of the box. Confidential information may be contained in this message. If you are not the address indicated in this message, please do not copy or deliver this message to anyone. In such case, you should notify the sender immediately and delete the original message.

Yeah, thank you Marek. For our use case we're using two tenants and we're already using the adapter, implementing the KeycloakConfigResolver interface. Our problem was when we've tried to use one tenant per client and when we've reached the 150 realms, during our tests. After that, we decided to keep one realm for internal users and only one realm for customers. Thank you Matteo On Tue, Sep 24, 2019 at 3:48 PM Marek Posolda <mposolda(a)redhat.com&gt; wrote: > On 24. 09. 19 15:15, Matteo Restelli wrote: > > For your interest. > We've evaluated internally the usage of many realms for customers and > we've encountered many issues, both on the frontend application (admin > console loading was really slow with 150-200 realms) and on the backend (in > the code there are places where it iterates between realms, loading a lot > of stuff). The cache helps, but i think that, for supporting multirealms, > there should be some refactoring / redesign of some components. > In addition, i think that some features like the sharing of a client > between realms (think of many tenants accessing the same single page > application, with the same client) need to be added. > > BTV. Not sure it helps with your use-case, but we have some multitenancy > on the adapter side too : > https://www.keycloak.org/docs/latest/securing_apps/index.html#_multi_tenancy > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keycloak.org_doc... > > Marek > > The segregation of realms is a really cool feature, but could cause > problems in a multi realm scenario (maybe introducing, also, some > hierarchical relationships between realms could be useful). > > Have a nice day, > Matteo > > On Tue, Sep 24, 2019 at 2:45 PM Marek Posolda <mposolda(a)redhat.com&gt; > wrote: > >> Hi, >> >> there is no change in this area. Big number of realms can be still an >> issue. We plan some refactoring of the storage layer in near future (1-2 >> years as very rough estimate) and that should help to address the >> multitenancy use-case among other things. >> >> Marek >> >> On 23. 09. 19 9:14, Litom Segal wrote: >> > We are considering using Keycloack in a multi-tenant fashion. >> > Each of our customer's account has its own users, and applications >> > installed, and we also provide services API's consumed by various >> clients. >> > We will have a large number of tenants. >> > I found an open issue from 2017 that mentions that Keycloak may have >> some >> > scalability issues with a large number of realms. >> > https://issues.jboss.org/browse/KEYCLOAK-4593 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_bro... >> > >> > And also this thread from 2016, >> > >> https://lists.jboss.org/pipermail/keycloak-user/2016-October/008033.html >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_pipe... >> , >> > that states that "Keycloak was not designed to support multi-tenancy >> > directly."..."In that regards we have never tested with high amounts of >> > realms as we expect there to be few realms (up to 10 most likely)." >> > >> > I was wonder if there was any progress on the multi-tenancy use case, >> and >> > are there any best practices on how to setup Keycloack to support it. >> > >> > On the other hand, is there any other approach to handle our use-case? >> > Thanks, >> > Litom >> > >> >> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mail... >> > > Like > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_cue... > I Follow > <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Cuebiq&a... > I Connect > <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_com... > > This email is reserved exclusively for sending and receiving messages > inherent working activities, and is not intended nor authorized for > personal use. Therefore, any outgoing messages or incoming response > messages will be treated as company messages and will be subject to the > corporate IT policy and may possibly to be read by persons other than by > the subscriber of the box. Confidential information may be contained in > this message. If you are not the address indicated in this message, please > do not copy or deliver this message to anyone. In such case, you should > notify the sender immediately and delete the original message. > > > Like <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_cue... I Follow <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_Cuebiq&a... I Connect <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_com... This email is reserved exclusively for sending and receiving messages inherent working activities, and is not intended nor authorized for personal use. Therefore, any outgoing messages or incoming response messages will be treated as company messages and will be subject to the corporate IT policy and may possibly to be read by persons other than by the subscriber of the box. Confidential information may be contained in this message. If you are not the address indicated in this message, please do not copy or deliver this message to anyone. In such case, you should notify the sender immediately and delete the original message.