[keycloak-dev] Hawkular requirements (was Re: RFC: organizations)

[Juraci Paixão Kröhling]

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:
https://docs.jboss.org/author/display/WFLY9/RBAC

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 "virtual-machine-1"

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