[keycloak-dev] roles vs. groups

[Bill Burke]

On 11/4/2015 6:32 AM, Pedro Igor Silva wrote:
>>
>> 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.
>>
>
> So my understanding is correct. This is what I meant by "GroupRole" relationships, which is also supported in PL. However, there we don't have roles within a group. But you can just assign any existing role to an user in the scope of a specific group.
>

What do you mean by "assign any existing role to an user in the scope of 
a specific group"?  User has Manager role for Group A?  So, the 
relationship (or join table) is User->Role->Group?  User would not have 
Manager role for Group B.  That relationship would have to be set up 
separately.

Isn't that different than "all users of Group A have the manager role"?

The difference would be in the token creation.  The former, "User has 
Manage role for Group A" would have to look like this:

"groups": [
    { "name" : "Group A",
      "roles" : [ "Manager" ]
    }
]

The latter "users of Group A have the manager role", would just add 
"manager" to the list of roles the user has:

"roles: ["Manager"]


There really is no equivalent in Java EE for leveraging a 
User/Role/Group relationship.  We'd have to add it to our adapters. 
Isn't "users of Group A have the manager role" enough?

> Regarding the overlap, there is no overlap with what I'm doing. What I'm doing is permission, what an user is actually allowed to do, considering the resources and the actions that can be performed on them (plus other things related authz). Like I said, we are going to use all the stuff you are doing to actually define permissions/policies for protected resources.
>
> Maybe the names "Permission" and "Rights" are not the best ones for what you are doing ? Maybe you should keep "Role Mapping" instead ? Conceptually, what you are doing is not permissions ...
>

So Role Mappings instead of Permissions for Groups.  I need a better 
name for "composite role".  I also need a better name for "Role Namespace".



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