[keycloak-user] Relationship of Groups to Roles?

Marek Posolda mposolda at redhat.com
Fri Dec 11 06:48:19 EST 2015


On 10/12/15 22:09, Marc Boorshtein wrote:
>> Roles in Keycloak are similar to Java EE roles.  Users are granted a
>> role, and become members of a Group.  Groups in Keycloak are a
>> collection of users.  Groups can have roles and attributes assigned to
>> them that user members inherit.
>>
> OK, so let me see if i'm conceptualizing this correctly.  I've created
> a role called "MyRole".  I have a group called "MyGroup" and a user
> named Matt Mosley (mmosley).  I can grant mmosley the role MyRole
> directly or I can add mmosley to MyGroup and grant MyGroup MyRole?
If you grant mmosley the role MyRole directly, it will be granted just 
to this user. If you grant MyRole to MyGroup, then the MyRole will be 
granted to each user added to the MyGroup. So you will just put 2 users 
to MyGroup: "mmosley", "mmosley2" and both will inherit MyRole.
> Additionally if the group MyGroup has an attribute x with the value y
> then mmosley, once assigned to MyGroup, would inherit the group
> attribute x=y?
yes
>
>
>> Clients/Applications work with roles, not with groups.   Applications
>> assign privileges to roles, not users or groups.  Keycloak currently
>> does not have the concept of Permissions/Entitlements.  Applications
>> have to handle how privileges are assigned to a role themselves.
>>
> I think we're saying the same thing here.  Roles are the integration
> point with KeyCloak (not groups) and its the application that gives a
> role meaning.
>
> So if I were to create a directory structure for an LDAP tree it would
> probably look something like:
>
> ou=keycloack
>    - ou=users
>      - uid=mmosley
>    - ou=groups
>     - cn=MyGroup
>    - ou=roles
>      - cn=myrole
>      - ou=app1
>        - cn=anAppSpecificRole
>
> OpenUnison doesn't have the concept of "roles" vs "groups".  So I
> would probably have all roles start with a "role." and groups start
> with a "group." so I can differentiate between them.
I am starting on adding LDAP Group Mapper to Keycloak and it will be 
(hopefully) available in 1.8. Mapper will allow you to specify in which 
DN are your groups and in which DN(s) are your roles (LDAP RoleMapper is 
already available, but I am planning some changes to 1.8, but it should 
remain backwards compatible).

So for your LDAP tree example, if you configure mappers like:
- Group Mapper: ou=groups,ou=keycloak
- Role Mappper for realm roles: ou=roles,ou=keycloak
- Role Mapper for client roles of client "app1": 
ou=app1,ou=roles,ou=keycloak

you will be able to map the environment. And you don't need to care 
about the names of roles, groups etc. because:
- LDAP group "cn=MyGroup,ou=groups,ou=keycloak" will be automatically 
treated as Keycloak group
- LDAP group "cn=myrole,ou=users,ou=keycloak" will be treated as 
Keycloak realm role
- LDAP group "cn=anAppSpecificRole,cn=app1,ou=roles,ou=keycloak" will be 
treated as client role of "app1" client

The Role Mapper is already available, so you can already try it out with 
1.7.

Marek
>
> Am I on the right track?  I've got Keycloak up and running so I'll
> play around with the apis too but didn't want to do that in a vacuum.
>
> Thanks
>
>
>> On 12/10/2015 3:33 PM, Marc Boorshtein wrote:
>>> I'm trying to wrap my head around the use cases where each would be
>>> used.  If I understand it correctly, a role a unit of authorization.
>>> Roles can have entitlements, either defined by Keycloak or an
>>> application.  A role can have other roles as members.  It can also
>>> have groups and individual users.  Groups aren't directly linked to
>>> entitlements, but are instead used to simply create a way to create a
>>> set of users (and groups).  Is this an accurate representation?
>>>
>>> I ask because I want to build some integrations between OpenUnison and
>>> MyVirtualDirectory.  Both work primarily on the LDAP concepts of
>>> users, groups and users.  Beyond SSO integration between OpenUnison
>>> and Keycloak, I'm looking at creating a provisioning target so
>>> OpenUnison workflows can provision access to Keycloak roles  as well
>>> as an insert for MyVirtualDirectory that can represent Keycloak roles
>>> and users as LDAP Objects for legacy applications.
>>>
>>> Thanks
>>>
>>>
>>> Marc Boorshtein
>>> CTO Tremolo Security
>>> marc.boorshtein at tremolosecurity.com
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



More information about the keycloak-user mailing list