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

Boleslaw Dawidowicz bdawidow at redhat.com
Tue Aug 4 09:49:42 EDT 2015 

Yes I agree we need them in KC. Was referring to more complex authz
scenarios and reqs.

On Tue, Aug 4, 2015 at 2:59 PM, Bill Burke <bburke at redhat.com> wrote:
> 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



-- 
--
Bolesław Dawidowicz

More information about the keycloak-dev mailing list