[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 3:18:43 PM
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> On 8/13/2015 2:23 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Wednesday, 12 August, 2015 3:50:21 PM
> >> Subject: [keycloak-dev] Groups design
> >>
> >> I would like to nail down what we want Groups to look like in Keycloak.
> >>    And also propose a separate RoleGroups structure.
> >>
> >> GROUPS:
> >>
> >> * Groups have an id, name, and description
> >> * Groups have an arbitrary set of name/value pair attributes
> >> * Realm/Client roles can be associated with a Group.  This is like a
> >> UserRoleMapping, except it is a GroupRoleMapping.
> >
> > With this concept we don't need composite roles and should remove them.
> >
> 
> We'd have to deprecate composite roles and remove them before product
> release.
> 
> >> * 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..

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

> 
> >>
> >> Features we probably want:
> >> * Groups can have a set of protocol Mappers organized by protocol.
> >> * Clients inherit protocol Mappers from the groups a user belongs to.
> >
> > I'm not sure groups should be the way to "share" protocol mappers. It would
> > be better to have realm level "protocol mapper definitions" that can be
> > re-used in clients. What you are suggesting raises a lot of questions:
> >
> 
> Basically a group or a role becomes a trigger for more behavior.
> 
> This is what Dell does if I understood them correctly.  They assign an
> "organization" based on the IDP that is logged in from.  Then populate
> the saml assertion/token based on what organization the user belongs to.
>   I you don't do something like this then you end up having to duplicate
> each mapper type or adding a "if group set" config option.
> 
> If user belongs to group and the attribute exists, add it to the
> assertion.  Rather than if attribute exists, add it to the assertion.
> 
> Conceivably might make sense to allow associating mappers with roles too.
> 
> 
> 
> 
> > * What happens when a user belongs to multiple groups that all have
> > protocol mappers associated. Seems like it would be very unclear in this
> > case what the token would actually look like. Especially if different
> > groups have conflicting mappings (for example one maps first-name to name
> > and another maps first+last name to name.
> 
> 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.

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

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

> 
> >>
> >>
> >> ROLEGROUPS:
> >>
> >> RoleGroups are just a namespace for Roles.  I want to remove the concept
> >> of realm level and client level roles and just have the concept of a
> >> RoleGroup.  The reasoning for this is that I've seen people ask for it.
> >>    They want to share a set of roles between clients and realm-level
> >> roles might end up having name clashes, if you are following me.
> >
> > +100000000000 I've wanted this from the start ;)
> >
> >>
> >> * RoleGroups have an id, name and description.
> >> * RoleGroups define a set of roles.
> >> * Users are *NOT* members of RoleGroups
> >> * For migration, a "realm" RoleGroup is created.  a RoleGroup for each
> >> client that has defined roles is created.  The name will be the clientId
> >> of the client.
> >> * I want to deprecate the "use-resource-role-mappings" switch in the
> >> adapter.
> >> * I want to deprecate the JWT extension we made for roles and have
> >> something completely flat (like SAML) with a URI that identifies each
> >> role (like in UMA spec).
> >
> > Would that be added to the scope field? Or something else? Scope allows
> > clients to request what goes into a token and there's a set of standard
> > things we need to support to achieve OIDC compliance.
> >
> 
> I don't see why it wouldn't be added to the scope field.
> 
> > How about JEE? It and other framework generally except simple names for
> > roles. We could make it configurable with the following options (assuming
> > the roles role://acme.org/role-group-a/role-a,
> > role://acme.org/role-group-b/role-b):
> >
> 
> 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.

> 
> > * Full - roles would be the full uris (role://acme.org/role-group-a/role-a,
> > role://acme.org/role-group-b/role-b)
> > * Simple - specify the "role-group" uri and only roles in that group are
> > included (if set to role://acme.org/role-group-a the roles are
> > role://acme.org/role-group-a/role-a)
> > * Stripped - includes roles that have a set prefix and removes the prefix
> > (if set to role://acme.org/ the roles are role-group-a/role-a and
> > role-group-b/role-b)
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>