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