[keycloak-dev] groups vs. organizations

[Scott Rehorn]

Hi Bill et al, comments below...

> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Monday, August 3, 2015 11:14 AM
> To: Scott Rehorn; keycloak-dev at lists.jboss.org
> Subject: Re: groups vs. organizations
> 
> 
> 
> On 8/3/2015 1:40 PM, Scott Rehorn wrote:
> >
> >
> > Here's a possible summary:
> > Groups:
> > * have names
> > * can contain other groups
> > * can carry a 'schema' which represent available attributes (more
> > generally, claims)
> > * support mapping and aggregation from IdP-defined groups
> > * can be assigned roles
> >
> > So user in a group gets that group's attributes, role associations, sub-group's
> role associations, sub-group's attributes.
> >
> 
> Can you define "support mapping and aggregation from IdP-defined groups"?
> Wouldn't this be something configured at each IDP rather than in a group?  The
> IDP would define a mapper that looked at some claim, then associate the user
> with a Keycloak defined group based on the claim...right?
> 

That's true - I mean both things are true :) I believe, in order to properly normalize things like group names in the authoritative location (where KC is the authority),  then the group name must be defined in KC and IdPs would map to that name as part of IdP mapping definitions. Of course, one could also *not* introduce mapping and just let each IdP pass through its own group definitions and let RPs sort it out themselves. 

> I was also thinking that we might remove client roles and just move them to
> groups.  Migration would be that a group is created for each client that has a set
> of roles defined.  We have a few users that want to share a set of roles between
> different clients.
> 

I partially agree with moving client roles to groups, but I think that the pattern that keeps appearing in the authZ department (role-based access control or RBAC) is to have this structure (including slightly different names and semantics):

* there are users
* users can be in groups
* groups can be in groups
* users and groups can be assigned roles
* roles can be assigned permissions (aka claims in this context)
* so a given user has a group, the group has n roles, and each role has m permissions attached to it -- an authenticated user has that little graph attached so an RP can interpret it to establish authZ decisions.
* a user can be assigned roles without using a group

I think your migration thinking is correct - and it opens up the chance to represent good granularity if it's needed, and basically ignored when it's overkill. I'm advocating for a permissions collection associated with a role, but there is an argument to say that having 'permissions' is nutty, since one can model simple authZ with a single-role-per-permission like KC roles do now. 

E.g., once authenticated, I might have a group 'Aliso Viejo R&D' and a set of roles which assert things like can-edit-bamboo-config, can-run-bamboo-build, etc. and I think that overloads the conventional meaning of a 'role' and that it's modeled a bit more tidily by having roles which act as named collections of permissions. 

Finally, where you said above "We have a few users that want to share a set of roles between different clients" then I think that's where the 'organization' type group comes into play. Clients A, B, C are in an 'org' (ok, group :) called 'tenant-20' which has a role called 'tenant-20-role' associated with it. This role, in turn, has claims/permissions. So any user authenticated by KC  into A, B, or C gets the claims expressed in the tenant-20-role. Further, only one of those users might be in an 'admin' group which has additional claims beyond those in the tenant-20-role.

- scott r



> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com