[keycloak-dev] Groups design

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 18 August, 2015 5:14:21 PM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> 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

Would be good if clients can import settings from client templates, but also override. Including adding mappers, maybe even removing mappers.

One thing about the name, templates could suggest it's only used at creation time. The effective mappers for a client should be updated when the client template is updated.

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

Sounds good

> 
> 
> 
> K, signing off until Thursday.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>