[keycloak-dev] groups vs. organizations

[Bill Burke]

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.

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?


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


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


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