[keycloak-dev] user groups vs. client groups

[Stian Thorgersen]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151105/0d8d5c42/attachment-0001.html