[keycloak-dev] RFC: organizations

[Scott Rehorn]

Comments inline...

On 7/28/15, 12:00 AM, "keycloak-dev-bounces at lists.jboss.org on behalf of
Stian Thorgersen" <keycloak-dev-bounces at lists.jboss.org on behalf of
stian at redhat.com> wrote:

>
>
>----- 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?

My mistake - I was abbreviating implicitly :) - I actually meant that the
URL would be more like /auth/admin/organizations.

>
>> 
>> 
>> 
>> 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.

That¹s correct. 

>
>> 
>> 
>> 
>> 
>> 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
>
>_______________________________________________
>keycloak-dev mailing list
>keycloak-dev at lists.jboss.org
>https://lists.jboss.org/mailman/listinfo/keycloak-dev