----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Pedro Igor Silva" <psilva(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, November 4, 2015 12:03:24 PM
Subject: Re: [keycloak-dev] roles vs. groups
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.
Yes, that is what I meant: "User has Manager role for Group A". And yes, User
would not have Manager role for Group B, only Group A.
Isn't that different than "all users of Group A have the manager role"?
Yeah, that is different. The case above is about inheriting roles from the group you are
member of, right ?
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" ]
}
]
+1
The latter "users of Group A have the manager role", would just add
"manager" to the list of roles the user has:
"roles: ["Manager"]
+1
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?
For most cases yes. But if you want to be more flexible you can support that as well.
IIRC, Hawkular wants group role. And it might be useful for others as well.
> 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