Re: [keycloak-dev] RFC: organizations

From: "Scott Rehorn" <srehorn(a)gmail.com&gt; To: keycloak-dev(a)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).

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.

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