[keycloak-dev] Hawkular Re: RFC: organizations

[Bill Burke]

Let's separate this discussion into Hawkular and Dell threads as they 
are coming at it similar at different angles.

We need some type of concept of group and/or organization.  But the 
discussion here is whether or not you can model Hawkular in Keycloak 
now, as it currently stands:

On 7/28/2015 5:09 AM, Juraci Paixão Kröhling wrote:
> 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.
>

What you could do is store a user attribute that defines the 
"organizational" metadata.  Then a client mapper that maps this metadata 
into the assertion/claim.  Then your application stores the 
organizational assertion as an attribute of the resource you create in 
the application's database.

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

1 roles =~ 100 bytes of information
2000 * 8 * 100 = 1.6 meg of data...What's the big deal?

Realm/client metadata is all cached too and almost never changes.  This 
is not an issue here.  What is the issue is that its a pain in the ass 
to maintain/migrate things as you would have to manage roles...



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

Well, your problem makes more sense now.  You have one client that 
manages multiple resources each of which the user could have different 
permissions.

Keycloak also has the concept of "Composite Roles".  A composite role is 
a role that is associated with other roles.  So, if a user has a 
user/role mapping of the composite, they also associatively have a 
mapping to the related roles.

So, you could define a composite role for each organization and 
associate roles with this composite.  Then users can be assigned these 
composite roles instead of each fine grain role.

Honestly though, it sounds like Hawkular might be more dynamic.  That 
resources can be created/destroyed quite often.  It might be best to use 
Keycloak mostly as an authentication mechanisms with only really coarse 
grain authorization.  And to store only basic organizational metadata 
about the user.  Keycloak shouldn't be used as a store for application 
specific metadata.  There's a point where you have to draw the line 
between an Identity store and an Application store.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com