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

Boleslaw Dawidowicz bdawidow at redhat.com
Tue Aug 4 06:57:39 EDT 2015 

+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



-- 
--
Bolesław Dawidowicz

More information about the keycloak-dev mailing list