[keycloak-dev] user groups vs. client groups

Fri Nov 6 01:48:40 EST 2015

On 5 November 2015 at 21:40, Stan Silvert <ssilvert at redhat.com> wrote:

> On 11/5/2015 2:36 PM, Stian Thorgersen wrote:
>
> We're only providing parts of RBAC now. The complete picture is what Pedro
> is working on with his AuthZ service.
>
> Yea, as I understand it, Pedro is doing P.  (P for Pedro!)  And also, he's
> filling in the rest of the gaps surrounding P.
>
>
> From the definitions above we're actually only providing S and R. SE is
> not a group as a group doesn't provide any permissions.
>
> Maybe that's a good reason to stick with the definitions below.  I see
> "Group" as a way to implement the mapping called for in SE.  But it doesn't
> have to be that way.
>

Group is not SE, I'm pretty sure of that. A group is just an "attribute" of
the subject. It doesn't "provide" any permissions or any mapping between
subjects and permissions.

>
>
> I'm not 100% sure what the group would be in the above, but I would think
> it's just part of S. A group is simply a means of assigning a role to a
> group of users.
>
>
> On 5 November 2015 at 20:24, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> We could do a lot worse than just following the basic RBAC design
>> described on Wikipedia:
>> https://en.wikipedia.org/wiki/Role-based_access_control
>>
>> Right now we're arguing over both definitions AND implementations.  It's
>> impossible to design this over email if we can't even settle on definitions.
>>
>> Therefore, I propose we just use the definitions in wikipedia.  At least
>> it's neutral.
>>
>>    - S = Subject = A person or automated agent
>>    - R = Role = Job function or title which defines an authority level
>>    - P = Permissions = An approval of a mode of access to a resource
>>    - SE = Session = A mapping involving S, R and/or P
>>    - SA = Subject Assignment
>>    - PA = Permission Assignment
>>    - RH = Partially ordered Role Hierarchy. RH can also be written: ≥
>>    (The notation: x ≥ y means that x inherits the permissions of y.)
>>       - A subject can have multiple roles.
>>       - A role can have multiple subjects.
>>       - A role can have many permissions.
>>       - A permission can be assigned to many roles.
>>       - An operation can be assigned many permissions.
>>       - A permission can be assigned to many operations.
>>
>>
>> Note: In my mind, S = keycloak user, and SE = keycloak group.  But
>> whatever, as long as we agree on definitions we can then decide what flavor
>> of RBAC to implement.
>>
>>
>> On 11/5/2015 1:44 PM, Stian Thorgersen wrote:
>>
>>
>>
>> On 5 November 2015 at 15:01, Bill Burke <bburke at redhat.com> wrote:
>>
>>>
>>>
>>> On 11/5/2015 6:23 AM, Stian Thorgersen wrote:
>>>
>>>>
>>>>
>>>> On 3 November 2015 at 22:20, Bill Burke <bburke at redhat.com
>>>> <mailto:bburke at redhat.com>> wrote:
>>>>
>>>>     In my previous email I talked about combining Groups and Role
>>>>     Namespaces.  Now I want to talk about User Groups vs. Client Groups.
>>>>
>>>>     User Groups would manage a set of users.  Members would
>>>> automatically
>>>>     inherit a set of "permissions": a set of roles.  User Groups would
>>>> also
>>>>     provide a set of attributes that the user inherits.
>>>>
>>>>
>>>> Permission != role
>>>>
>>>>
>>>>     I'd like to introduce the concept of a Client Group.  Client Group
>>>> would
>>>>     have:
>>>>
>>>>     * Roles - basically a role namespace
>>>>
>>>>
>>>> -1 Having roles tied to a client or client group is exactly what we
>>>> should go away from. IMO role namespaces should be a completely separate
>>>> thing.
>>>>
>>>>
>>> I don't agree at all.  If User Groups and Client Groups exist, there is
>>> no need for role namespaces.  It is stupid to have to create another
>>> concept (role namespace) to define the roles one specific client or a group
>>> of clients expects.
>>>
>>
>> I've never the concept of realm and client roles. It's been difficult to
>> explain and strange to use. I've always just used realm roles. It's a
>> strange and limiting concept. Introducing client groups with further places
>> to define roles just makes matters even worse. Now users have two go 3
>> different places to define roles:
>>
>> * Realm
>> * Client Groups
>> * Clients
>>
>> What happens if a client group and a client both have the same role by
>> the way?
>>
>> It's a strange limitation. At least personally if I was using Keycloak I
>> would simply use realm roles alone and define my own hierarchy with a
>> delimiter.
>>
>> It's much better to have a single place to define roles, under the roles
>> tab. Then allow users can define the namespaces/hierarchy they want.
>>
>> Role namespaces are easier to deal with and at the same time more
>> flexible.
>>
>> I just don't see any reason why we would have roles specific to a client
>> or client group.
>>
>>
>>>
>>> If you combine Role namespace and Groups you can define things like a
>>> group admin role.  Roles that mean something to the group.
>>>
>>>
>>>     Each Client Group would have some default roles defined.  i.e. roles
>>>>     that allow a user to edit any client in the client group.
>>>>
>>>>
>>>> I don't understand this
>>>>
>>>>
>>> A Client Group could have a "client group admin" role.  If a user has
>>> that role it can manage clients in the group.  Another role might be
>>> "client membership admin".  This role allows a user to add or remove
>>> clients from the group.
>>>
>>> Conversely, user groups could have a "user group admin".  When granted,
>>> this role allows a user to manage users in the group.  YOu can also do
>>> things like define a "Manager" role for the group.  This "Manager" would be
>>> granted "user group admin" privileges and also granted access to other
>>> systems like "HR", "Attendence", "Benefits", etc.
>>>
>>> I think this permission concept should be built into Keycloak as it is a
>>> core feature.  I'll write u a separate email about this.
>>
>>
>> This is another reason why we need role namespaces. With a role namespace
>> we can define internal roles that then don't end up conflicting with users
>> own roles. For example as we have a role admin atm users can't define their
>> own admin role and will have to name it differently.
>>
>> I think the fact that we have internal abstract clients to be able to
>> create a namespace for internal admin roles speaks for itself.
>>
>>
>>>
>>>
>>>
>>>
>>>>     Each Client would have the same configuration options.  They would
>>>> be
>>>>     able to have an additional set of roles, permissions, scope, and
>>>>     overridable Protocol Policies.
>>>>
>>>>
>>>> Same comment as above - why would a client have roles/permissions? I
>>>> assume we where moving away from that with role namespaces
>>>>
>>>>
>>> Again, I think role namespaces are redundant.
>>>
>>> A client can define a set of roles that it offers.  A service account
>>> (the client) can have roles associated with it so it can do certain actions.
>>
>>
>> Some will want to have roles associated with a client (email-user), but
>> others have organizational wide roles (manager, sales-guy, etc..). Role
>> namespaces can deal with both, but client roles can't.
>>
>>
>>>
>>>
>>>
>>>
>>> --
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151106/59a98578/attachment.html 