<div dir="ltr">Hello Bill, Stian, and the rest of the keycloak-dev list from Dell Software (software division of Dell Computers). <div><br></div><div>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. </div><div><br></div><div><p class="MsoNormal">Proposal: introduce a new entity called "organizations" to
provide a means of delivering specific claim values to authenticated users
known in that organization</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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. </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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).</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">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 *<b>can</b>*
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. </p><p class="MsoNormal"><br></p><p class="MsoNormal">Thanks for your attention and we look forward to working with you. </p><p class="MsoNormal"><br></p><p class="MsoNormal">- scott r</p><p class="MsoNormal"><br></p></div></div>