[keycloak-dev] Users and Realms
Federico Michele Facca
federico.facca at martel-innovate.com
Fri May 17 10:46:41 EDT 2019
Indeed "Realms of Realms" sounds nice :)
Regarding token size, this is true. Currently we trick this by using the
mapper on the in the user profile (we want tokens to be minimal).
Anyhow, ideally, we would like to have this information in the token for a
specific tenant to reduce api interactions (so far the only way
we thought is to use a scope for each tenant and use this scope to generate
the output of the mapper - of course if you have any better idea,
that will not break the standard OIDC, we are happy to try).
Cheers,
Federico
On Fri, 17 May 2019 at 16:35, Pedro Igor Silva <psilva at redhat.com> wrote:
> 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 at martel-innovate.com> wrote:
>
>> 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>
>>
>
--
*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