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(a)tremolosecurity.com
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user