Re: [keycloak-dev] RFC: organizations

From: "Juraci Paixão Kröhling" <jpkroehling(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 28 July, 2015 11:09:04 AM Subject: Re: [keycloak-dev] RFC: organizations 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.