On 8/18/2015 9:14 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)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(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> Cc: keycloak-dev(a)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(),
>>>>>>> * Similar to default roles, we also have default groups.
>>>>>> If we add default groups we don't need default roles and
>>>>> Not sure I agree. Users may not want roles.
>>>> You mean may not want groups? I just don't like maintaining multiple
>>>> 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
>> 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
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
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.
* Deprecate Composite Roles. Remove with the product cut
* Deprecate Default Roles. Remove with the product cut.
K, signing off until Thursday.
JBoss, a division of Red Hat