7:53 a.m.
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