Agree, Keycloak (as an authentication server) should be limited to providing roles (and
other claims/attributes, maybe we can groups and even roles within groups).
We could look at adding something more of an authorization server (UMA) where a resource
provider uses the users token to contact the authorization server to check if a user has a
specific permission on a specific resources. It's an interesting challenge and maybe
something we can look at in the future, but I think it's going to be mid-end 2016 at
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
Sent: Tuesday, 28 July, 2015 6:08:05 PM
Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations)
I think it is appropriate to model resource access separately, outside
of Keycloak. The reason for this is basically how SAML/OIDC and single
sign in works. It should be:
1. User visits Hawkular
2. User is redirected to Keycloak to login
3. User logins in
4. User is redirected back to Hawkular with a set of assertions
If you were using Keycloak to model resource access, then Hawkular would
have to continuously hit Keycloak in the background to
* create/destroy/modify resource definitions
* enable/disable permissions of the user for each resource
* verify permissions of the user for each resource
I just don't think an authentication server should be used to manage
application data. Would you require that a company's LDAP store start
storing Hawkular specific metadata to manage all these resources? No.
You would not. Which is why I think Keycloak should only be storing
things like does this user belong to this group or organization. That's
it. Keycloak should not be managing access to the resources of a
On 7/28/2015 9:57 AM, Juraci Paixão Kröhling wrote:
> Sure. Please, keep in mind that we have two possible deployment
> scenarios: SaaS and Hosted.
> For SaaS (and some specific customers on Hosted), we need to have multi
> tenancy, so, data from one "organization" should be isolated from
> another. At the same time, we need users from one organization to
> possibly have access to data from other organizations.
> Note that we use the same role names and semantics as Wildfly:
> Case #1, simplest possible scenario:
> - a new user registers on Hawkular SaaS and wants to monitor a website.
> No one else should have access to the metrics collected for this user.
> Case #2, most complex scenario:
> - Acme, Inc has several departments: Marketing, Sales and so on. Each
> one has a small operations team, which is responsible for their
> day-to-day activities (creating a database, adding an application
> server, deploying an application, increasing memory, ...).
> - A member of the Marketing department should not be able to view/manage
> resources from, say, Sales.
> - Acme, Inc has a NOC, which is responsible for the 24x7 monitoring.
> They should have read-only access to metrics from all machines of Acme,
> Inc, no matter which department.
> We are currently solving this by having "Hawkular Accounts" to sit
> between Keycloak and the Hawkular modules (Alerts, Metrics, Inventory,
> ...) and providing a "Current Persona". This "persona" is a
> representation of the tenant + the rights that the user has for this
> tenant. So, the Persona might be an User acting as Monitor on an
> Organization, or might be an User acting on its own Resources as
> SuperUser. Permission checking is performed on the business side by the
> modules, by calling an API which is similar to PicketLink's Permission API.
> So, we have the following concepts on Hawkular Accounts:
> - Organization
> - "Acme, Inc"
> - Roles
> - SuperUser
> - Monitor
> - Auditor
> - ...
> - User
> - "jmuller"
> - Persona
> - "jmuller"
> - "jmuller" acting as "SuperUser" of "Acme, Inc"
> - Resource
> - "virtual-machine-1"
> - "travel-request-webapp"
> - Operation
> - "add-memory"
> - "monitor-cpu"
> - "deploy-war"
> - "read-datasources"
> - Permission
> - "SuperUser" can "add-memory" to
> - Organization membership
> - "jmuller" is "SuperUser" on "Acme, Inc"
> - "Acme, Inc" is "SuperUser" on "Acme Sales"
> - "Acme NOC" is "Monitor" on "Acme, Inc"
> On the simplest case (case 1):
> - User is Persona. So, when the user registers and adds the website to
> be monitored, the website is owned by the user (ie: SuperUser of
> Resource is User).
> On the complex case (case 2):
> - User jmuller registers and creates the organization "Acme, Inc" and
> is, therefore, the SuperUser of it.
> - User jmuller switches the context to "Acme, Inc" on the UI
> - Acme Sales is created as an Organization inside Acme, Inc (Acme, Inc
> owns it)
> - Acme Marketing is created as an Organization inside Acme, Inc (ditto)
> - Acme NOC is created as an Organization inside Acme, Inc (ditto)
> - User jmuller invites jdoe to be SuperUser of Acme Sales
> - User jdoe switches the context to "Acme Sales" on the UI
> - Acme Sales (via jdoe) creates the host "acme-sales-prod-1" and is the
> SuperUser of it.
> - As jdoe is a SuperUser member of Acme Sales, jdoe is therefore
> SuperUser of "acme-sales-prod-1"
> - User jmuller invites jsmith to be SuperUser of Acme NOC
> - Organization Acme NOC is granted Monitor on Acme, Inc
> - As jsmith is a SuperUser of NOC, but as NOC is only Monitor on Acme,
> Inc, then jsmith is also only Monitor on Acme Sales.
> - User jmuller is SuperUser on "Acme, Inc", so, is also a SuperUser of
> "Acme Sales", "Acme Marketing", "Acme NOC".
> - User jim creates "Red Hat, Inc", which has no access to Acme, Inc data.
> When the user jsmith (SuperUser of NOC) selects "Acme Sales" on the
> Hawkular Accounts switcher, an HTTP header is sent with the request,
> with the ID of the "Acme Sales" as the Persona-ID. When an operation
> needs to be done in a resource that is owned by Acme Sales, the relevant
> Hawkular module asks Hawkular Accounts whether the current persona can
> perform the Operation on the Resource. On this case, jsmith is only
> Monitor on Acme Sales, so, if it's a read only operation, the permission
> is granted.
> I realize that there are terms which are specific to Hawkular, but I
> tried to make it as clear as possible for those who have no knowledge of
> those terms. In case something is not clear, let me know.
> - Juca.
> On 07/28/2015 02:19 PM, Stian Thorgersen wrote:
>> 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(a)redhat.com>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> 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
>>> 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
>>>> 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
>>> Meaning that for each new "organization", a new set of roles would
>>> 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,
>>>> A user can now have a role mapping on acme-super to get all roles for
>>>> clients, or you can add role mappings to individual roles within each
>>> 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
>>> 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
>>>> Email Reader' could either have a scope on all roles within
>>>> 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
>>> - Juca.
> keycloak-dev mailing list
JBoss, a division of Red Hat
keycloak-dev mailing list