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

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

I agree

But, if someone wants to add some default roles to a user, why would they care if it's done through adding a default group and adding roles to that, rather than adding default roles directly? If we remove composite roles, it more or less makes the default roles feature a bit useless in either case, so would be better to use groups for it.

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

I disagree - KC is supposed to be easy to use, that should include the advanced features as well. We shouldn't create something that by design would potential be hard to use.

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

I'm not at all convinced ;)

It'll be more important to be able to share a set of protocol mappers between clients. So a client should be able to define it's own protocol mappers, and it should be possible to define protocol mappers groups (or whatever it's called) at the realm level and re-use those. One issue with a shared protocol mappers group is that would define the "token format", but you then loose the ability to define what attributes/claims each client should retrieve.

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

Can you elaborate on it a bit more then? As I see it:

* Identity brokers should be able to add a mapper that defines what groups a user belongs to
* Clients should be able to use a "group" mapper to add a group to the token. The group mapper would add the attributes and roles associated with the group to the token.

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