[keycloak-dev] user groups vs. client groups

Thu Nov 5 14:36:06 EST 2015

We're only providing parts of RBAC now. The complete picture is what Pedro
is working on with his AuthZ service.

>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.

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/20151105/964fa220/attachment.html 