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

Bill Burke bburke at redhat.com
Tue Aug 4 08:59:46 EDT 2015 

We still want to have some concept of groups.  I think I'm coming to 
some sort of design for them which I'll post soon.

On 8/4/2015 6:57 AM, Boleslaw Dawidowicz wrote:
> +1. The more I think about it I lean towards having something
> separate. Another component/server to handle more reach robust
> authorisation needs while being tightly integrated with authentication
> server.
>
> It is a pandora box and when you start collecting requirements you
> quickly reach permissions, inheritance or dynamic rule based
> resolution. Would have high impact on usability and simplicity.
>
> On Wed, Jul 29, 2015 at 9:05 AM, Stian Thorgersen <stian at redhat.com> wrote:
>> 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 least.
>>
>> ----- Original Message -----
>>> From: "Bill Burke" <bburke at redhat.com>
>>> To: keycloak-dev at lists.jboss.org
>>> 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
>>> 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
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>> _______________________________________________
>> 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

More information about the keycloak-dev mailing list