[keycloak-dev] RFC: organizations

[Stian Thorgersen]

----- Original Message -----
> From: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Tuesday, 28 July, 2015 10:18:21 AM
> Subject: Re: [keycloak-dev] RFC: organizations
> 
> On 07/28/2015 09:04 AM, Stian Thorgersen wrote:
> >
> > ----- Original Message -----
> >> From: "Juraci Paixão Kröhling" <juraci at kroehling.de>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Tuesday, 28 July, 2015 8:12:14 AM
> >> Subject: Re: [keycloak-dev] RFC: organizations
> >>
> >> We have a *very* similar use case and we have implemented the notion of
> >> "Organizations" (and "Personas") in Hawkular, in a module named
> >> "Hawkular Accounts". In our case, an user can belong to multiple
> >> organizations, and can have different roles within each organization
> >> ("Super User" in "Operations", but "Monitor" on "Marketing").
> >
> > Can you not already model that in Keycloak by having a separate clients for
> > "Operations" and "Marketing" with the corresponding roles?
> 
> With the current features related to Clients, it might actually be
> possible. Would it be possible to restrict which users can login with
> which clients? For instance:
> 
> - jdoe registers
> - jdoe creates "Acme, Inc" (and is then super user there)
> - jsmith registers
> - jsmith creates "Red Hat, Inc" (and is then super user there)
> - jdoe invites jsmith to "Acme, Inc" to be "Monitor" there
> 
> So:
> - jdoe should never have access to "Red Hat, Inc"
> - jsmith should have access to:
>    - his "own" resources (not part of any organization)
>    - resources owned by "Acme, Inc" (as Monitor)
>    - resources owned by "Red Hat, Inc" (as Super User).
> 
> This scenario is the main reason why we have Hawkular Accounts between
> the individual HK components and Keycloak. With this covered, I think
> pretty much all of the other use cases can be worked out quite easily.

I'll add a bit to this example:

Within a realm there's 4 services (bearer-only clients):

* Acme Email Service
* Acme Monitor Service
* Red Hat Email Service
* Red Hat Monitor Service

Each client has one or more roles. For example Acme Email and Red Hat email both have view-email, read-email and send-email.

To model the above super users you'd add two composite realm roles:

* acme-super - add mapping on all roles for Acme Email and Acme Monitor
* redhat-super - add mapping on all roles for Red Hat Email and Red Hat Monitor

A user can now have a role mapping on acme-super to get all roles for Acme clients, or you can add role mappings to individual roles within each client.

That's what you want isn't it?

Further you can also utilize scope on applications (confidential for server-side web app, or public for client-side web apps) to limit the roles a application can obtain. For example the HTML5 application 'Acme Email Reader' could either have a scope on all roles within 'Acme Email Service' or 'acme-super'. It should probably not have scope on any roles for 'Red Hat Email'.

> 
> - Juca.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev