[keycloak-dev] roles vs. groups

[Bill Burke]

On 11/3/2015 5:01 PM, Pedro Igor Silva wrote:
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, November 3, 2015 7:04:43 PM
>> Subject: [keycloak-dev] roles vs. groups
>>
>> Stian and I were having a conversation about roles, keycloak composite
>> roles, vs. groups.  It seems that groups and roles are often confused
>> and one can be equivalent to the other.  One common thread is the following:
>>
>> Groups are user centric. Roles are permission centric.
>>
>> "A group is a means of organising users, whereas a role is usually a
>> means of organising rights."
>
> IMO, groups can also be used to organize rights. It is quite common to only check if an user is member of a group or any of its parents. Despite any role ...
>
> In any case, handle groups and roles separately is the best way to go ...
>
>>
>> So, keycloak composite roles would be a way to organise rights for a set
>> of applications.  For example, you might have a set of sales services,
>> each sales service has an "admin" and "user" role.  You'd define a
>> "sales user" and "sales admin" role which would be a composite
>> containing the "admin" and/or "user" role of each sales service.
>>
>> Conversely, a keycloak group would provide a way to organize a set of
>> users.  You would create a group called "sales associates" add members
>> to it and then assign the roles members of the group can partake.
>>
>> Really, in Keycloak with composite roles, you can have a role act as a
>> group.  So, while groups and roles are logically the sameAdding the
>> concept of a group though provides distinction and clarity without
>> overloading the concept of a composite.
>
> +1
>
> Regarding "role act as a group". Yes, you can. And that is what JEE gives you and it is not enough when you really need to support the group concept, specially when you need to consider group hierarchies, permission inherited to members, etc. You need some role mapping hack to get all that working.
>
> IMO, Role (or composite role) != Group ...
>
>>
>> So, given that, Role mapping tab for Groups and Users would be named
>> "Permissions" instead of "Role Mappings".  Each role would have a
>> "Rights" tab instead of the "Composite Role" concept we have now.  That
>> might bring more clarity?  Or will it just confuse concepts that are
>> going to be introduced by Pedro and his Authz stuff?
>
> Basically, what you are doing is group and role mapping in the end. Where you can add "permissions" to an group or an user.
>
> The Authz stuff will just use whatever you define in order to write policies for your protected resources. For instance, we can now define a Group-Based Policy, so you can say that all members of a group (or any of its parents) can access a resource or perform some operation on it.
>
> Or even say that any member with a role X within a group can do something.
>
>>
>> I'm also thinking that a Groups and Role Namespaces could be combined.
>> So a group would have a set of "Permissions" (role mappings) that are
>> automatically granted to user members.  The group could also define a
>> set of "Roles" that apply to this group.  So "Sales" could have a
>> "Manager" role.  This "Manager" role would be a composite role that
>> assigns additional permissions.  This would also allow us to define
>> default roles for
>
>> Whoops, I didn't finish....
>> Combining Groups and Role Namespaces would allow us to define built in
>> roles for the Group that when assigned would allow management of the
>> members of the group.
>
> If I got this properly, what you mean is support "GroupRole" relationships. Where you may say that Bill is Manager in Group A.
>
> IIRC, Hawkular requires that.
>

I'm just proposing a role namespace.  i.e. Group A defines a role called 
"Manager".  Bill has role mapping A.Manager.  I want to avoid 
overlapping with what you are doing.  Each group would have some built 
in declared roles:  i.e. add-user, manage-user, manage-group, etc...So 
that a user can be permitted to manage the members of the group.  A few 
people have been asking for this.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com