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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)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(a)redhat.com&gt; >>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>> Cc: keycloak-dev(a)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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev