[keycloak-dev] Groups design

[Bill Burke]

On 8/18/2015 9:14 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Thursday, 13 August, 2015 4:35:50 PM
>> Subject: Re: [keycloak-dev] Groups design
>>
>>
>>
>> On 8/13/2015 10:17 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke at redhat.com>
>>>> To: "Stian Thorgersen" <stian at redhat.com>
>>>> Cc: keycloak-dev at lists.jboss.org
>>>> Sent: Thursday, 13 August, 2015 4:03:18 PM
>>>> Subject: Re: [keycloak-dev] Groups design
>>>>
>>>>
>>>>
>>>> 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.
>>>
>>> It's still extra stuff that needs documenting/explaining and for users to
>>> understand. Having multiple things that does the "same thing" is a good
>>> way of making software complicated IMO.
>>>
>>
>> Its not the same thing.  Its a convenience thing as with your proposal
>> you have the extra step of creating the default group.
>
> IMO it's the same thing. Having two options increases the amount of concepts a user has to understand, increases documentation, etc..
>
> More importantly if we remove composite roles and replace fully with groups, then default roles are much less usable.
>
> My vote is to remove default roles and just have default groups, then focus on making it easy to do the required setup around it.
>

I don't really care that much, but you still have to worry about 
migration and document how old default roles/role composites map onto 
the new Group model.

>>
>> I don't think a Group mapper would conflict with other Group mappers as
>> they would generally be concerned with mapping attribute and roles that
>> are defined within the Group.
>
> Sure, but a user could be member of many groups, where each groups in turn could be members of other groups. IMO this will just end up messy even with a relatively simple group hierarchy.
>

Only messy if there are conflicting mappers which IMO will be unlikely.

>
> I think I've misunderstood what you've suggested. Is it correct that:
>
> * A realm has one or more "group mappers"
> * A client belongs to one or more "group mappers"
>
> If so, it sounds good. I think a flat structure is good enough though (no a group mapper can have one or more group mappers etc..).
>
> Group mappers is probably a horrible name, so client template sounds much better.
>

I think we'll just have Client Templates where you can define common 
protocol settings and common mappers.

That's different than what I was proposing before.  User belong to 
Group.  A Group has a set of mappers.  A user's group;s mappers are 
applied to the token automatically.  I think its an interesting concept 
but am fine not having it.

So, decision making time?

Have the concept of Client Templates:
* protocol settings
* mappers


Have the concept of User Groups
* Users belong to User Groups
* User Groups have attributes and role mappings

Have the concept of Role Groups:
* Role Groups are just a namespace for roles.


Other actions:

* Deprecate Composite Roles.  Remove with the product cut
* Deprecate Default Roles.  Remove with the product cut.



K, signing off until Thursday.

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