From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 28 July, 2015 8:12:14 AM Subject: Re: [keycloak-dev] RFC: organizations Scott, On 07/28/2015 04:12 AM, Scott Rehorn wrote: > Proposal: introduce a new entity called "organizations" to provide a > means of delivering specific claim values to authenticated users known > in that organization > > Rationale: in our group at Dell Software, we have to support the notion > of tenancy within a single realm, but we are trying to avoid the term > ‘tenant’ as it’s too overloaded. Our typical use case is to use > Keycloak+our extensions as an external system which acts as identity > broker for a constrained set of IdPs and claims authority for users. If > we use realm-per-organization, then we wind up with a large set of > repeated IdP configurations. By introducing an entity for > “organizations” then we have a centralized place to store metadata for > users and related client/RP instances. We have a *very* similar use case and we have implemented the notion of "Organizations" (and "Personas") in Hawkular, in a module named "Hawkular Accounts". In our case, an user can belong to multiple organizations, and can have different roles within each organization ("Super User" in "Operations", but "Monitor" on "Marketing").

If our use cases converge, I think we should work together on this. Our code is currently located here and includes some documentation about how it works and what's our use case: https://github.com/hawkular/hawkular-accounts - Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Juraci Paixão Kröhling" <jpkroehling(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 28 July, 2015 10:18:21 AM Subject: Re: [keycloak-dev] RFC: organizations On 07/28/2015 09:04 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; >> To: keycloak-dev(a)lists.jboss.org >> Sent: Tuesday, 28 July, 2015 8:12:14 AM >> Subject: Re: [keycloak-dev] RFC: organizations >> >> We have a *very* similar use case and we have implemented the notion of >> "Organizations" (and "Personas") in Hawkular, in a module named >> "Hawkular Accounts". In our case, an user can belong to multiple >> organizations, and can have different roles within each organization >> ("Super User" in "Operations", but "Monitor" on "Marketing"). > > Can you not already model that in Keycloak by having a separate clients for > "Operations" and "Marketing" with the corresponding roles? With the current features related to Clients, it might actually be possible. Would it be possible to restrict which users can login with which clients? For instance: - jdoe registers - jdoe creates "Acme, Inc" (and is then super user there) - jsmith registers - jsmith creates "Red Hat, Inc" (and is then super user there) - jdoe invites jsmith to "Acme, Inc" to be "Monitor" there So: - jdoe should never have access to "Red Hat, Inc" - jsmith should have access to: - his "own" resources (not part of any organization) - resources owned by "Acme, Inc" (as Monitor) - resources owned by "Red Hat, Inc" (as Super User). This scenario is the main reason why we have Hawkular Accounts between the individual HK components and Keycloak. With this covered, I think pretty much all of the other use cases can be worked out quite easily.

- Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.

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

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

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(a)redhat.com&gt; > 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(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 > > > > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; To: keycloak-dev(a)lists.jboss.org Sent: Wednesday, 29 July, 2015 9:48:45 AM Subject: Re: [keycloak-dev] Hawkular requirements (was Re: RFC: organizations) On 07/28/2015 06:08 PM, Bill Burke wrote: > 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: Indeed. Which is basically what we have today. But if Organizations were something that would be implemented in Keycloak, I could focus on Operations/Resources/Permissions, while Organizations/Roles/Users would still be managed by Keycloak. But I'm afraid that our use case is too specific to be useful to the community as a whole, even if we take only the organization part into consideration.

- Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 07/29/2015 09:57 AM, Stian Thorgersen wrote: > Can you not just add a realm role to represent an "organization"? So, each organization would be a realm? Not sure that would solve the use cases I presented before, specially this part: - 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. I did try to play a bit with this idea a bit locally, but I'm not sure I'm reproducing correctly what you have in mind. - Juca. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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.