[keycloak-dev] RFC: organizations

[Stian Thorgersen]

----- Original Message -----
> From: "Scott Rehorn" <srehorn at gmail.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 28 July, 2015 4:12:08 AM
> Subject: [keycloak-dev] RFC: organizations
> 
> Hello Bill, Stian, and the rest of the keycloak-dev list from Dell Software
> (software division of Dell Computers).
> 
> As Bill and Stian already know, our team at Dell has been integrating our own
> extensions to Keycloak to build a SaaS-based identity broker, and Bill and
> Stian suggested that we run the first of our main extensions out into the
> mailing list for further discussion. Here is an overview to solicit some
> first impressions and additional ideas in this area. We think this extension
> is necessary for our own use cases, and, if it seems like a broadly useful
> modification, then we can contribute the code for it.
> 
> 
> 
> Proposal: introduce a new entity called "organizations" to provide a means of
> delivering specific claim values to authenticated users known in that
> organization
> 
> 
> 
> Rationale: in our group at Dell Software, we have to support the notion of
> tenancy within a single realm, but we are trying to avoid the term ‘tenant’
> as it’s too overloaded. Our typical use case is to use Keycloak+our
> extensions as an external system which acts as identity broker for a
> constrained set of IdPs and claims authority for users. If we use
> realm-per-organization, then we wind up with a large set of repeated IdP
> configurations. By introducing an entity for “organizations” then we have a
> centralized place to store metadata for users and related client/RP
> instances.
> 
> 
> 
> Example: clients A and B are SSO apps which both use KC for authentication
> and authorization. If a user logs into client A, he is redirected to an IdP
> (via Keycloak brokering) where he authenticates. After authentication, the
> user of client A receives in his claimset additional assertions, e.g.,
> subscriptionId=2057 and organizationName=CheeseCompany which are derived
> from the org definition which says that the authenticated user belongs to
> Cheese Company under a particular subscription. A different user in a
> different organization would have a different subscription to and would
> receive a different subscriptionId and organizationName
> 
> 
> 
> Implementation strategy and code impact: our current implementation is
> derived from the IdentityProviders model and exposes an API only at
> '/organizations'. We haven’t done the UI level, but it would be similar to
> the identity providers UX (top-level admin managed item in left menu).

What's '/organizations' used for? If it's to view/configure organizations shouldn't it be contained within the admin endpoints?

> 
> 
> 
> Relationship to ‘groups’: we think that the concept of organizations is
> conceptually distinct enough to treat it as a hierarchical construct. An
> organization can have IdPs and users it recognizes, and such grouping of
> related clients needing common assertions could be accomplished with groups,
> but our current thinking is that the groups-everywhere approach is a little
> too general – e.g., you * can * simulate relational database semantics with
> tags and selections based on combinations of tags, but when something is
> clearly hierarchical, why not use a hierarchy? Groups would be a separate
> construct could then be treated as tags to enable multiple memberships etc.,
> much like roles are handled in KC now.

I don't quite understand how this works. Is the following correct or not:

* A realm has one or more organizations
* An organization has one or more attributes (key -> value pairs)
* A user is associated with one or more organizations
* An IdP is associated with one or more organizations

Then when a user logs in the attributes available would be the union of:

* Attributes from organization associated with IdP (if IdP was used to authenticate)
* Attributes from organization associated with user
* Attributes from user

Further token contains attributes as configured by mappers for client.

> 
> 
> 
> 
> Thanks for your attention and we look forward to working with you.
> 
> 
> 
> 
> - scott r
> 
> 
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev