[keycloak-dev] Groups design

[Bill Burke]

On 8/13/2015 9:32 AM, Stian Thorgersen wrote:

>>>> * Groups can be members of one or more groups
>>>> * Users can be members of one or more groups
>>>> * Users inherit attributes of the groups they belong to.
>>>> * UserModel now has a getGroups(), hasGroup(), grantGroup(), deleteGroup()
>>>> * Similar to default roles, we also have default groups.
>>>
>>> If we add default groups we don't need default roles and should remove
>>> them.
>>>
>>
>> Not sure I agree.  Users may not want roles.
>
> You mean may not want groups? I just don't like maintaining multiple ways to achieve the same thing - extra work for us and complicates documentation, etc..
>

Yeah, sorry, users just might not create any groups, plus its backward 
compatible to keep default roles.  The extra work to add default groups 
is simple.  Its just duplication of the equivalent role code.

> Why not just have a default group? Then users can add whatever roles and other groups they want to it?
>

I don't like a "default group" for the same reason I don't like these 
pseudo "built in" clients.


>> Not really our problem.  If somebody does an overcomplicated design,
>> that's their problem.
>
> I think it is. It would be very hard for a user to interpret what would end up in the token even with relatively simple groups.
>

Still, I dont think its our problem.  They can choose not to use the 
feature.

>>
>>> * Shouldn't token format be defined by a client, not by groups? A client
>>> will expect a token is a certain format, but if it's dependent on what
>>> group a user belongs to all bets is off.
>>>
>>
>> Probably depends on the app.  But that's a good point.  Just seem cool
>> to be able to assign behavior to a group or even a role, rather than
>> assigning behavior to the client.
>
> I'd rather think that groups are the source of the information. So the available claims are:
>
> * Users roles and attributes
> * Groups roles and attributes
>
> But, then you still have a set of protocol mappers (either specified on a per-client as now, or ability to share these) that takes these claims and adds it to the token.
>

Another way of looking at it is that the group defines of how attributes 
and roles look inside the claim/assertion, rather than the client 
defining how an attribute looks.

I'm not entirely convinced is a great thing to have, but it does seem 
like it would be useful.


>>
>>>>
>>>> Questions:
>>>> * Do we want to expand the concept of a Group so that clients and
>>>> identity brokers can belong to a Group? Or just create a separate
>>>> composite structure for this?
>>>
>>> Not sure we need that at all. Can't identity brokers and clients just use
>>> mappings to achieve the required effect? Or am I confusing what effect
>>> this would have.
>>>
>>
>> The concept of associating mappers to a Group isn't required, its just a
>> different way of attacking the problem.
>
> I don't like alternatives ;)
>

I don't think it is an alternative.  It is just allowing the Group 
decide how to map things.


>> We could add role-name mapping at the adapter level.  I wanted to avoid
>> that as it would all have to be done in config files.
>
> True, but I think it's needed. With the client endpoints I'm adding the plan was that clients can self-register, discover their config as well as update their config. Once we have that it would be nice to have adapters retrieve config from KC.
>

I guess role-name mapping on the client side would be pretty simple if 
each role has a URI.


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