[keycloak-dev] RFC: organizations

[Stian Thorgersen]

I think we've successfully managed to abstract ourselves completely away from your real requirements ;)

Can you start another thread listing your exact requirements? Then we can see if it's possible to model it with existing roles, client roles and composite roles.

----- Original Message -----
> From: "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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.
>