[keycloak-dev] Groups design

[Bill Burke]

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.

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

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

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

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

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