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

Wed Jul 29 03:05:09 EDT 2015

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