9:12 p.m.
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