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

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(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 _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev