[keycloak-dev] Groups design

[Stian Thorgersen]

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

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

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

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

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

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

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

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

> * We will remove these deprecated features in the final cut of community
> that we fork to move into product.
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>