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

Tue Jul 28 12:08:05 EDT 2015

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

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:
> 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.
>>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

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