3:31 a.m.
----- Original Message -----
From: "Juraci Paixão Kröhling"
<jpkroehling(a)redhat.com>
To: keycloak-dev(a)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(a)kroehling.de>
>> To: keycloak-dev(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev