[keycloak-dev] Users and Realms
Federico Michele Facca
federico.facca at martel-innovate.com
Fri May 17 09:47:18 EDT 2019
Dear Pedro,
On Fri, 17 May 2019 at 15:03, Pedro Igor Silva <psilva at redhat.com> 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 at martel-innovate.com> 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 at redhat.com> 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 at 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>
More information about the keycloak-dev
mailing list