[keycloak-dev] RFC: organizations

[Juraci Paixão Kröhling]

On 07/28/2015 10:31 AM, Stian Thorgersen wrote:
> 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

Is there a way to have a relationship between Acme Email Service and 
Acme Monitor Service? Are they different clients? We'd need a stable ID 
between related services, which would be our "tenant". So, if user jdoe 
creates a resource in our application while acting as SuperUser for 
Acme, we have to store this resource with the information that it 
belongs to Acme, so that users of Red Hat wouldn't have access to it.

> 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

Meaning that for each new "organization", a new set of roles would have 
to be duplicated. Basically, acme-super and redhat-super are exactly the 
same, except for the names.

But if I get it right, this is how it would look like:

- user jdoe registers, is "super" on the realm itself
- user jdoe creates Acme, and is acme-super there, effectively being 
super on the client
- user jsmith creates Red Hat, invites jdoe as "monitor" there
- user jdoe is now super on the realm, acme-super on the Acme client and 
redhat-monitor on the Red Hat client.

So, if a request comes in to our backend for jdoe while using the UI as 
Red Hat, our backend would see only "redhat-monitor" as the role, right?

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

This means that I would be able to be Super User on Acme, but only 
Monitor on Red Hat, right?

> That's what you want isn't it?

I think it could work, yes, but that doesn't feel right, to be honest. 
It seems like we'd be doing some workarounds to implement a concept that 
doesn't quite exist on Keycloak, which would cause a massive data 
duplication. For one realm containing two clients and 8 roles each, this 
seems doable, but for one realm containing 2.000 clients (nested or not) 
and 8 roles each, that *sounds* like a maintenance/migration/performance 
nightmare.

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

Sounds like a bonus feature, but I don't think this would bring any 
benefit for us. We have only one frontend and one backend (with several 
modules). So, the same application available to Acme is available to Red 
Hat.

- Juca.