Hi, As you know, currently users belong to a realm and as such, you can't share them across different realms. We always had people looking for alternatives about how to solve this problem where all the available options have their pros and cons. I would like to see what you think about decoupling users from realms in a way that user federation and management are completely decoupled from realms so that users (or group of users) can be *associated* with realms. As an example, here is how you would configure users and realms in Keycloak: 1) Configure your identity stores/user federation from where users will be fetched. Or create users in Keycloak. 2) Assign to your users a label or a logical group. This assignment could be done manually or even automatically depending on: a) default group where all users are in b) the identity store from where users are fetched c) based on the user's email (domain) d) anything else that makes sense 3) Create a realm and specify which users should belong to a realm based on these labels or groups. A realm should be able to have users with different labels/groups. The realm definition/configuration would not change much as it stands today. Each of them would still have their own way of managing realm specific groups and roles. Regards. Pedro Igor _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Good to know about your approach to multi-tenancy. It is an interesting solution. On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca < federico.facca(a)martel-innovate.com&gt; wrote: > Dear Pedro, > this is a very relevant discussion to us. We currently solved the issue > using a single realm, > and using "root" level groups with a attribute "tenant=true". We have > then created a custom > client to manage this configuration from the single "tenant" admin > perspective. > Could you elaborate more on that, please? I understand how you are using groups and the tenant attribute, but what you exactly mean by "custom client to manage this configuration" ? I guess you all your tenants share the same security policies defined on the realm level too?

> > This solution for us allows to manage "multi-tenancy" also at the single > oidc client without > much complexity (your approach wouldn't allow for that, right?) > Do your users have access to different tenants? When issuing tokens to these users, do you have roles within the token for each tenant the user belongs to?

> Of course we had to use some tricks to do fine grained control access, > which is basically working under the assumption you attach users to > groups and you > manage roles attached to groups and not to users. Then, within the token, > we return > user roles per client based on their group membership. > > Cheers, > Federico > > On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > >> Hi, >> >> As you know, currently users belong to a realm and as such, you can't >> share >> them across different realms. We always had people looking for >> alternatives >> about how to solve this problem where all the available options have >> their >> pros and cons. >> >> I would like to see what you think about decoupling users from realms in >> a >> way that user federation and management are completely decoupled from >> realms so that users (or group of users) can be *associated* with realms. >> >> As an example, here is how you would configure users and realms in >> Keycloak: >> >> 1) Configure your identity stores/user federation from where users will >> be >> fetched. Or create users in Keycloak. >> >> 2) Assign to your users a label or a logical group. This assignment could >> be done manually or even automatically depending on: >> >> a) default group where all users are in >> b) the identity store from where users are fetched >> c) based on the user's email (domain) >> d) anything else that makes sense >> >> 3) Create a realm and specify which users should belong to a realm based >> on >> these labels or groups. A realm should be able to have users with >> different >> labels/groups. >> >> The realm definition/configuration would not change much as it stands >> today. Each of them would still have their own way of managing realm >> specific groups and roles. >> >> Regards. >> Pedro Igor >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >> > > > -- > *Dr. FEDERICO MICHELE FACCA* > *CTO, Head of Martel Lab* > +41 788075838 > *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE > MAKE IT HAPPEN > Click *HERE* to download Martel reports and white papers! > <https://www.martel-innovate.com/premium-content/> > Follow us on *TWITTER* <https://twitter.com/Martel_Innovate> >

Yes, it makes the configuration and management easier by avoiding multiple realms with the same client replicated on each of them. But it also has some cons as all your tenants share the same security policies (as they are within a single realm) and your tokens size would increase a lot depending on how many tenants the user can access. For the latter, you should be able to workaround by using client scopes or improving the logic in your mapper. With my proposal, some issues you are trying to avoid would still be there, such as client replication. Which could be addressed by having some provisioning logic that could be used automatically create a realm accordingly with your needs. In fact, this is something that could also be addressed by the "Realms of Realms" approach that Bruno mentioned. However, you would still have the standard Keycloak model but with the possibility to have the same user across different realms, each realm with distinct policies, configuration, etc. On Fri, May 17, 2019 at 10:47 AM Federico Michele Facca < federico.facca(a)martel-innovate.com&gt; wrote: > Dear Pedro, > > On Fri, 17 May 2019 at 15:03, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > >> Good to know about your approach to multi-tenancy. It is an interesting >> solution. >> >> On Thu, May 16, 2019 at 4:55 PM Federico Michele Facca < >> federico.facca(a)martel-innovate.com&gt; wrote: >> >>> Dear Pedro, >>> this is a very relevant discussion to us. We currently solved the issue >>> using a single realm, >>> and using "root" level groups with a attribute "tenant=true". We have >>> then created a custom >>> client to manage this configuration from the single "tenant" admin >>> perspective. >>> >> >> Could you elaborate more on that, please? I understand how you are using >> groups and the tenant attribute, but what you exactly mean by "custom >> client to manage this configuration" ? >> >> I guess you all your tenants share the same security policies defined on >> the realm level too? >> > > we have a custom script mapper associated to a "tenants" default scope > that inject the needed information either in the token or in the user > profile. > > the mapper return something like: > > "tenants": [ > { > "name": "Wolfsburg", > "groups": [ > { > "parent": "Wolfsburg", > "realmRoles": [ > "offline_access" > ], > "name": "Admin", > "clientRoles": [ > "uma_protection", > "entity:delete", > "group:create", > "device:read", > "group:write", > "registration:create", > "endpoint:create", > "subscription:write", > "entitytype:read", > "user:delete", > "subscription:read", > "endpoint:read", > "group:read", > "device:create", > "subscription:create", > "devicegroup:create", > "devicegroup:write", > "endpoint:delete", > "group:delete", > "registration:write", > "user:read", > "endpoint:write", > "entity:read", > "entity:create", > "devicegroup:read", > "user:create", > "registration:read", > "registration:delete", > "entity:write", > "devicegroup:delete", > "user:write", > "subscription:delete", > "device:delete", > "device:write" > ] > }, > { > "parent": "Wolfsburg", > "realmRoles": [ > "offline_access" > ], > "name": "User", > "clientRoles": [ > "uma_protection", > "entity:read", > "device:read", > "devicegroup:read", > "registration:read", > "entitytype:read", > "subscription:read", > "endpoint:read" > ] > }, > { > "parent": "Wolfsburg", > "realmRoles": [], > "name": "WasteManagement", > "is_servicepath": true > } > ], > "id": "f6b3d2e5-0064-4d0b-8cea-6e378f2cfff2" > }, > { > "name": "Vecciano", > "groups": [ > { > "parent": "Vecciano", > "realmRoles": [], > "name": "Admin", > "clientRoles": [ > "entity:delete", > "group:create", > "device:read", > "group:write", > "registration:create", > "endpoint:create", > "subscription:write", > "entitytype:read", > "user:delete", > "subscription:read", > "endpoint:read", > "group:read", > "device:create", > "subscription:create", > "devicegroup:create", > "devicegroup:write", > "endpoint:delete", > "group:delete", > "registration:write", > "user:read", > "endpoint:write", > "entity:read", > "entity:create", > "devicegroup:read", > "user:create", > "registration:read", > "registration:delete", > "entity:write", > "devicegroup:delete", > "user:write", > "subscription:delete", > "device:delete", > "device:write" > ] > } > ], > "id": "c088dbc0-a01c-45fc-9304-926cd881e690" > } > ], > > >> >> >>> >>> This solution for us allows to manage "multi-tenancy" also at the >>> single oidc client without >>> much complexity (your approach wouldn't allow for that, right?) >>> >> >> Do your users have access to different tenants? When issuing tokens to >> these users, do you have roles within the token for each tenant the user >> belongs to? >> > > yes, user have access to different tenants. as you saw above we have > roles per tenants. > we are thinking of adding some mechanism (based on scope or claims ?) to > return only roles for a specific tenant of the user. > > This solution allows to avoid to replicate the same configuration of a > client across different realms, which would be quite annoying. > I suppose it's not optimal, but we couldn't think of anything better. > > Cheers, > Federico > > >> >> >>> Of course we had to use some tricks to do fine grained control access, >>> which is basically working under the assumption you attach users to >>> groups and you >>> manage roles attached to groups and not to users. Then, within the >>> token, we return >>> user roles per client based on their group membership. >>> >>> Cheers, >>> Federico >>> >>> On Thu, 16 May 2019 at 17:55, Pedro Igor Silva <psilva(a)redhat.com&gt; >>> wrote: >>> >>>> Hi, >>>> >>>> As you know, currently users belong to a realm and as such, you can't >>>> share >>>> them across different realms. We always had people looking for >>>> alternatives >>>> about how to solve this problem where all the available options have >>>> their >>>> pros and cons. >>>> >>>> I would like to see what you think about decoupling users from realms >>>> in a >>>> way that user federation and management are completely decoupled from >>>> realms so that users (or group of users) can be *associated* with >>>> realms. >>>> >>>> As an example, here is how you would configure users and realms in >>>> Keycloak: >>>> >>>> 1) Configure your identity stores/user federation from where users >>>> will be >>>> fetched. Or create users in Keycloak. >>>> >>>> 2) Assign to your users a label or a logical group. This assignment >>>> could >>>> be done manually or even automatically depending on: >>>> >>>> a) default group where all users are in >>>> b) the identity store from where users are fetched >>>> c) based on the user's email (domain) >>>> d) anything else that makes sense >>>> >>>> 3) Create a realm and specify which users should belong to a realm >>>> based on >>>> these labels or groups. A realm should be able to have users with >>>> different >>>> labels/groups. >>>> >>>> The realm definition/configuration would not change much as it stands >>>> today. Each of them would still have their own way of managing realm >>>> specific groups and roles. >>>> >>>> Regards. >>>> Pedro Igor >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>> >>> >>> >>> -- >>> *Dr. FEDERICO MICHELE FACCA* >>> *CTO, Head of Martel Lab* >>> +41 788075838 >>> *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE >>> MAKE IT HAPPEN >>> Click *HERE* to download Martel reports and white papers! >>> <https://www.martel-innovate.com/premium-content/> >>> Follow us on *TWITTER* <https://twitter.com/Martel_Innovate> >>> >> > > -- > *Dr. FEDERICO MICHELE FACCA* > *CTO, Head of Martel Lab* > +41 788075838 > *MARTEL INNOVATE* <https://www.martel-innovate.com/> - INNOVATION, WE > MAKE IT HAPPEN > Click *HERE* to download Martel reports and white papers! > <https://www.martel-innovate.com/premium-content/> > Follow us on *TWITTER* <https://twitter.com/Martel_Innovate> >

Hi, As you know, currently users belong to a realm and as such, you can't share them across different realms. We always had people looking for alternatives about how to solve this problem where all the available options have their pros and cons. I would like to see what you think about decoupling users from realms in a way that user federation and management are completely decoupled from realms so that users (or group of users) can be *associated* with realms. As an example, here is how you would configure users and realms in Keycloak: 1) Configure your identity stores/user federation from where users will be fetched. Or create users in Keycloak. 2) Assign to your users a label or a logical group. This assignment could be done manually or even automatically depending on: a) default group where all users are in b) the identity store from where users are fetched c) based on the user's email (domain) d) anything else that makes sense 3) Create a realm and specify which users should belong to a realm based on these labels or groups. A realm should be able to have users with different labels/groups. The realm definition/configuration would not change much as it stands today. Each of them would still have their own way of managing realm specific groups and roles. Regards. Pedro Igor _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Hi, As you know, currently users belong to a realm and as such, you can't share them across different realms. We always had people looking for alternatives about how to solve this problem where all the available options have their pros and cons. I would like to see what you think about decoupling users from realms in a way that user federation and management are completely decoupled from realms so that users (or group of users) can be *associated* with realms. As an example, here is how you would configure users and realms in Keycloak: 1) Configure your identity stores/user federation from where users will be fetched. Or create users in Keycloak. 2) Assign to your users a label or a logical group. This assignment could be done manually or even automatically depending on: a) default group where all users are in b) the identity store from where users are fetched c) based on the user's email (domain) d) anything else that makes sense 3) Create a realm and specify which users should belong to a realm based on these labels or groups. A realm should be able to have users with different labels/groups. The realm definition/configuration would not change much as it stands today. Each of them would still have their own way of managing realm specific groups and roles. Regards. Pedro Igor _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev