----- Original Message ----- > 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). 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev