[keycloak-dev] Groups design

[Scott Rehorn]

We've been watching the groups discussion with interest over the last week or so, and we have a some comments and input re your proposed 'groups' implementation:
 
* our simple, purpose-built 'organizations' requirements can be readily subsumed by a group. It's possible that an 'organization' construct might still be useful as an organization structure similar in function to the 'client template' at the client level, but we'll see. 

* We generally feel that the group construct should have attributes associated with it - i.e., a user who is a member of a group gets attributes added to his token. The example we like best is 'subscriptionId' (with some value associated with it) as an attribute associated with a group so that a user identified as a member of that group always has that name-value pair in his token. We consider this an important means to support cooperating clients. 

* In our discussions, we tend to believe that 'permissions' are separate from 'roles', but it's not a deal-killer. That is, a role is a collection of permissions, but you can arrive at the same thing by naming convention in roles, e.g., admin-can-perform-backup, admin-can-reboot, etc. The usual treatments of role-based access control separate permissions from roles but that might be a function of academic purity. 

* +1 for client templates: this seems like a very helpful construct for organizing configuration patterns (for protocol, IdPs, etc.). Generally the 'client template' seems like a good location to specify a consistent group assignment based on incoming IdP. E.g., a CT could specify that for client x, any user who logs in with one of the available IdPs for that client, automatically gets put into x-users-group. The term 'membership' seems good here: membership defines the group(s) that a given user should belong to as part of client-x. 

* We think the distinction could be emphasized that groups can be only users and/or other groups and are thus for organizational applications and distinct from roles/permissions. If people make nested groups with conflicting role assignments, that could be trouble, but IMO indicates a larger authZ definition issue that KC shouldn't be involved in. 

* The "RoleGroup" concept seems strained, and/or we don't understand the use case. Firstly, using the word 'group' in there is dangerous :). If it's just 'namespace' for roles, then maybe just simple tagging for Roles would be sufficient as a means to collect related roles? Or attach that association in the client template? 

* You mention that having the URI for a role name is awkward, and, true, it can be a pain, but it's worth noting that it can be a 'urn:' which doesn't need to include a deployment-host-based DNS-based name. A URN is a clean way to express a canonical easily-read identifier (as opposed to a guid or something). 

* When you say 'deprecate {default,composite} roles' you just mean that a user's collection of roles is no longer named that way? It's still important for a user to wind up with a collection of roles which are certainly composites (due to possible role assertions contributed by an IdP, or as a result of group membership). 

* Just to see if we understand the boundaries and responsibilities for mappers:
  - Claims arriving from an IdP can be mapped to the token, relabeling them
  - Group and role assignments are mapped into the token for an authenticated user
  - These mapper configs are governed by client implementers (for better or worse) and implemented as client template directives 

* Task for The Intern Riding a Unicorn: have a debug UX which creates and displays a token in the admin interface so one could fiddle with the mappers and group assignments without having to write an external client to see the resulting token :)

* We think it's implicit, but just to be sure: the group membership collection will also be in the token, correct? So a token has group membership, role association, any claims mapped from the IdP, group-defined attributes, and user-level attributes. 
 

- scott r
(On behalf of the identity broker team at Dell Software)

> -----Original Message-----
> From: keycloak-dev-bounces at lists.jboss.org [mailto:keycloak-dev-
> bounces at lists.jboss.org] On Behalf Of Stian Thorgersen
> Sent: Wednesday, August 19, 2015 11:50 PM
> To: Bill Burke <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Subject: Re: [keycloak-dev] Groups design
> 
> 
> 
> ----- 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, 20 August, 2015 3:53:28 AM
> > Subject: Re: [keycloak-dev] Groups design
> >
> >
> >
> > On 8/19/2015 3:17 AM, Stian Thorgersen wrote:
> > >>> Have the concept of Role Groups:
> > >>> * Role Groups are just a namespace for roles.
> > >
> > > Just to double check as part of this we're removing the concept of
> > > realm and client roles, and we're also adding some ability of
> > > defining what roles are listed in adapters (so we can have plain
> > > role names, like 'user', in jee apps for example)
> > >
> >
> > Yes.  We'll have a flat user role mapping in the token
> >
> > roles: [ "role1", "role2" ]
> >
> > You'll either manipulate how roles look in the token via a mapper, or
> > you'll define a role mapping within the adapter config.  Default role
> > mapper on server will specify a URI for the role.  BTW, this URI
> > probably shouldn't have a DNS name within it.  Something like
> > role:{realm-name}.{group}.{role-name}.  This is so that adapter config
> > doesn't have to be changed as it moves from dev->QE->production.  BTW,
> > this is why I hate the OIDC requirement that the realm is some http://
> > based URI.
> 
> Do we need real-name? Seems like that'll only make it hard to use.
> 
> I like OIDC requirement that it's URL based - a realm is not a unique name,
> but a URL is and I think it should be unique
> 
> >
> >
> > --
> > 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