[keycloak-dev] groups vs. organizations

[Scott Rehorn]

Comments below...

> -----Original Message-----
> From: Bill Burke [mailto:bburke at redhat.com]
> Sent: Friday, July 31, 2015 2:25 PM
> To: Scott Rehorn <Scott.Rehorn at software.dell.com>; keycloak-
> dev at lists.jboss.org
> Subject: Re: groups vs. organizations
> 
> 
> 
> On 7/31/2015 2:42 PM, Scott Rehorn wrote:
> > I think it is true that an organization is kind of a special case of a
> > Œgroup¹. We had specific requirements for the concept of what amounted
> > to a single group just to bind a few shared attributes between related
> > relying parties (clients). We decided to deliberately push a group
> > concept for Œlater¹ because there are a bunch of complicating factors with
> groups.
> > One is that groups are often defined in people¹s IdPs (esp. with
> > Active Directory), and the policy for mapping or merging those defs
> > dragged in more complexity than we wanted to do right away. Another is
> > that groups often want to be nested and that¹s again more complexity
> > than we were willing to bite off for so simple a function as an org.
> >
> 
> You're going to have to explain what this complication is as it relates to
> people's IDPs and AD/LDAP.  Also, we have already dealt with nesting via
> Composite Roles in Keycloak so its not that big a deal.
> 

One of the main attractions for doing federation for us was to help move away from the definition of groups inside AD which is a common occurrence in the world -- even though it doesn't belong in AD in a brokered or federated model. Our main concern was about reconciliation and propagation of IdP-defined groups into a federated model. If people have already defined groups such that the claims returned contained group definitions, then the broker would have to introduce more mapping to make sure all the groups expressed properly in the final claimset. This isn't particularly difficult, but supporting it was going to drag in more code than we wanted to write just to support an entity where we could hang some shared attributes.  


> Maybe we shouldn't call it a "Group" or an "Organization".  Stian floated the
> idea of calling it a Composite.  Maybe that is just too developery/engineery
> and not Opssy/Sys Adminny enough and we need to have "Group" and
> "Organization" even though they are the same concept logically?
> 

Engineery heh, yes. I think the implementation probably doesn't require a separate model (group vs. organization), and it's probably enough just to use 'group' as opposed to 'composite' - an org is would be just another group with a tag to enable 'organization' semantics, whatever that works out to be. Could be rendered in the UI slightly differently, but, under the hood, it's groups. 

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. 

> 
> > To answer your specific question about the specific common set of
> > attributes - if I¹m following your question, we reluctantly call this
> >   ¹schema¹ in that it¹s a known, predefined set of attribute keys
> > which can have arbitrary values (and that new attribute keys are not
> > normally added by userland code). We have expectation that defining
> > attributes as enforceable ³schema" (including validation for values)
> > is a feature that will be required for orgs and users but our first cut doesn¹t
> go that far.
> >
> 
> Yeah, I guess there would be similar but not necessarily common schema.
>   An organization could be a set of companies who are your customers and
> would have different metadata than organizations that are a divisions and
> teams in your own company.
> 
> One question I have for you guys, is what does it mean for a client to belong
> to a Dell organization/tenant?  What if a broker belongs to an organization?
> Are they inheriting a set of mappers or something?
> 

A client in a Dell 'org' is just a client which would receive attributes defined at the org level. The motivation was to support two (or n) cooperating SaaS applications, each with their own tenancy model. For example: App A creates a 'tenant/custoemr' in its own representation, App B creates its own tenant. Dell has a subscription model so a customer gets access to A and B via subscription with id "2057". The identity broker (DIB/KC) establishes an organization for subscription 2057 with trusted set of IdPs and any user who authenticates through the broker in that org gets the subscription id 2057 in his claimset. We sort of expect mapping to be widely variable - some will need lots of mapping between the broker and IdP and others, less. 

> 
> > So I think that while organizations *could* be implemented as a group
> > with special constraints, it would stretch the abstraction a little too far.
> 
> I don't see how an organization implemented as a group would stretch the
> abstraction too far.  They both can have users as members and users would
> inherit their attributes.  Both let their users inherit metadata.
>   Both have arbitrary attribute schemas.
> 
> While groups and organizations might be different concepts to an admin,
> logically they work in the same exact way.  For example, we used to have a
> distinction between Applications and OAuth Clients.  We merged them
> because it was just a lot of duplicate code and caused a lot of additional
> clutter in the UI and the concepts were almost identical.  I don't want to
> create the same situation with Groups and Organizations then have to go
> back and merge the concepts later on.
> 
> The most important thing is to have a UI that covers most use cases and that
> is easy to understand.  This means we need to constantly improve and
> consolidate the UI.  Make things simpler.  Have intuitive default behavior,
> and so on.  The reason Stian and I founded Keycloak was because we were
> so sick of how complex security was.
> 

Agreed on all counts - having an entity to represent a 'group' construct is robust enough to present to users via UI as groups, and then also surface it as an organization construct so it's easy to see how to collect cooperating clients. 

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