I am comparing OPA authorization to Keycloak - how could I enforce Keycloak policy in the SQL closest to the data for good performance, including returning subsets of lists?  OPA discusses this at https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq.... Thanks! Rob Byrd DST Solutions Lead SS&C Technologies Inc.   |   1055 Broadway, Kansas City, MO 64105 t: (816) 435-7286  | m (816) 509-0119 rmbyrd@dstsystems.com<mailto:rmbyrd@dstsystems.com>  |  www.ssctech.com<http://www.ssctech.com/>; > > Follow us: [cid:image001.png@01D412C1.A14C5770] <https://www.linkedin.com/company/ss-c-technologies/>  |  [cid:image002... <https://twitter.com/ssctechnologies>  |  [cid:image003.png@01D412C1.A1... <https://www.facebook.com/ssctechnologies/> Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

(Hope this is the correct way to reply - let me know if not) Thanks. So my concern is really with the whole idea that an Enterprise Application's security constraints could really be all implemented based on url-patterns, is that what you guys are thinking? For example, mostly a user can visit most features (urls) in an application, but it is the subset of things they can see/do within the feature that is the crux of the security issue - and it does not seem feasible to architect urls in such a way that they can be used as the key to security. Thoughts? Thanks! Rob Byrd DST Solutions Lead SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 t: (816) 435-7286 | m (816) 509-0119 rmbyrd(a)dstsystems.com | www.ssctech.com Follow us: | | -----Original Message----- From: Dmitry Telegin [mailto:dt@acutus.pro] Sent: Friday, November 2, 2018 12:22 AM To: Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user(a)lists.jboss.org Subject: Re: [keycloak-user] Data filtering in SQL Hello Rob, If I get it right, it's all about generating SQL WHERE clause from Keycloak policies? I think this is doable, as Keycloak has a well-defined object model for authorization policies, and it's easy to obtain policy definitions in JSON format. I think Pedro Igor will tell you more about that. You should pay attention to the following: - there are differences in semantics between OPA and Keycloak policies. For example, Keycloak policies do not operate HTTP methods but rather use more generic notion of scopes; - not every policy type can be easily converted to a WHERE clause. It should be trivial for User/Group/Role policies, but is virtually impossible for Script and Rules, as they are just blackboxes that evaluate to true or false. Unless of course your DBMS has a built-in JavaScript engine :) Good luck! Dmitry Telegin CTO, Acutus s.r.o. Keycloak Consulting and Training Pod lipami street 339/52, 130 00 Prague 3, Czech Republic +42 (022) 888-30-71 E-mail: info(a)acutus.pro On Thu, 2018-11-01 at 21:39 +0000, Byrd, Rob M wrote: > I am comparing OPA authorization to Keycloak - how could I enforce Keycloak policy in the SQL closest to the data for good performance, including returning subsets of lists? OPA discusses this at https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... . > > Thanks! > > Rob Byrd > DST > Solutions Lead > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > t: (816) 435-7286 | m (816) 509-0119 > rmbyrd@dstsystems.com<mailto:rmbyrd@dstsystems.com> | www.ssctech.com< http://www.ssctech.com/>; > > > Follow us: [cid:image001.png@01D412C1.A14C5770] < https://www.linkedin.com/company/ss-c-technologies/ > | [cid:image002.png@01D412C1.A14C5770] < https://twitter.com/ssctechnologies > | [cid:image003.png@01D412C1.A14C5770] < https://www.facebook.com/ssctechnologies/> > > > > Please consider the environment before printing this email and any attachments. > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Hi Rob, On Tue, 2018-11-06 at 16:28 +0000, Byrd, Rob M wrote: > (Hope this is the correct way to reply - let me know if not) > > Thanks. So my concern is really with the whole idea that an Enterprise Application's security constraints could really be all implemented based on url-patterns, is that what you guys are thinking? Cannot speak for Keycloak guys, but will put in my 2¢ as an architect - URL-based (or rather resource-based) authorization covers only one aspect of the application security. Data filtering is equally important, but it's just another facet of the problem, and needs to be solved accordingly. Indeed, Keycloak doesn't provide OOTB any means for automatically limiting subsets of data shown to the user, as Keycloak has a completely different scope (namely Web SSO/IDM solution). However, you can still use Keycloak as a central warehouse for your security (meta)data, and use it the way you want. Like I said before, nothing stops you from defining some policies in Keycloak, then retrieving them and converting to a WHERE clause for your SQL/JPQL/NoSQL query. Speaking of NoSQL - this might be not directly relevant to your problem, but still interesting. A similar problem has surfaced in the discussion following my talk on Apache Sling + Keycloak [1] earlier this year; the central point was: "okay, we can have Keycloak path-based authorization in Sling, but how do we limit the content visible to the user?" That time we came up with some sort of hybrid solution, like path-based security + JCR ACLs and/or application-level rules; but now I think this might be something similar, like generating JCR's equivalent to the WHERE clause based on Keycloak policy definition. Just to make sure I understand the case, let's imagine: - there are users and groups (live in Keycloak); - there are, say, "projects" (live in business tier + DB); - there is a policy in Keycloak saying "projects should be accessible only to the members of the respective groups"; - based on that: - GET /projects/<project> should return 200 + representation if the user is a member of the group, 403 otherwise; - GET /projects should return the list of projects the current user has access to. Is this correct? [1] https://adapt.to/2018/en/schedule/modern-authentication-in-sling-with-ope... Cheers, Dmitry Telegin CTO, Acutus s.r.o. Keycloak Consulting and Training Pod lipami street 339/52, 130 00 Prague 3, Czech Republic +42 (022) 888-30-71 E-mail: info(a)acutus.pro > > For example, mostly a user can visit most features (urls) in an application, but it is the subset of things they can see/do within the feature that is the crux of the security issue - and it does not seem feasible to architect urls in such a way that they can be used as the key to security. Thoughts? > > Thanks! > > Rob Byrd > DST > Solutions Lead > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > t: (816) 435-7286 | m (816) 509-0119 > rmbyrd(a)dstsystems.com | www.ssctech.com > Follow us: | | > > -----Original Message----- > > From: Dmitry Telegin [mailto:dt@acutus.pro] > Sent: Friday, November 2, 2018 12:22 AM > > To: Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user(a)lists.jboss.org > Subject: Re: [keycloak-user] Data filtering in SQL > > Hello Rob, > > If I get it right, it's all about generating SQL WHERE clause from Keycloak policies? I think this is doable, as Keycloak has a well-defined object model for authorization policies, and it's easy to obtain policy definitions in JSON format. I think Pedro Igor will tell you more about that. > > You should pay attention to the following: > - there are differences in semantics between OPA and Keycloak policies. For example, Keycloak policies do not operate HTTP methods but rather use more generic notion of scopes; > - not every policy type can be easily converted to a WHERE clause. It should be trivial for User/Group/Role policies, but is virtually impossible for Script and Rules, as they are just blackboxes that evaluate to true or false. Unless of course your DBMS has a built-in JavaScript engine :) > > Good luck! > Dmitry Telegin > CTO, Acutus s.r.o. > Keycloak Consulting and Training > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic > +42 (022) 888-30-71 > E-mail: info(a)acutus.pro > > On Thu, 2018-11-01 at 21:39 +0000, Byrd, Rob M wrote: > > I am comparing OPA authorization to Keycloak - how could I enforce Keycloak policy in the SQL closest to the data for good performance, including returning subsets of lists? OPA discusses this at https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... . > > > > Thanks! > > > > Rob Byrd > > DST > > Solutions Lead > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > t: (816) 435-7286 | m (816) 509-0119 > > rmbyrd@dstsystems.com<mailto:rmbyrd@dstsystems.com> | www.ssctech.com<http://www.ssctech.com/>;; > > > > Follow us: [cid:image001.png@01D412C1.A14C5770] < https://www.linkedin.com/company/ss-c-technologies/ > | [cid:image002.png@01D412C1.A14C5770] < https://twitter.com/ssctechnologies > | [cid:image003.png@01D412C1.A14C5770] < https://www.facebook.com/ssctechnologies/> > > > > > > > > Please consider the environment before printing this email and any attachments. > > > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > Please consider the environment before printing this email and any attachments. > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

Thanks Dmitry and Pedro, Pardon my simple-minded response below, but I am wondering how these specific items would work? Dmitry, yes I agree your GET /projects/<project> and GET /projects scenario is on point for the issue – I hope my questions below can further clarify the discussion. Here, I will have to make a “go or no-go” decision in about a week. J I would love to take on the challenge of searching for the “holy grail” in this, but atm will need to figure out what Keycloak (or OPA, etc.) can confidently do today. Thanks for the great discussion and continued help! Questions 1) Simple role-based authorization policy seems doable. - Ex: “Only veterinarians are allowed to read pet profiles.” 2) But how to answer once more context is needed, such as one resource’s affinity to another? Literally how does the application figure it out? Like the below example would need a pet-veterinarian mapping resolved somehow, it seems: - “Only the treating veterinarian is allowed to read a pet’s profile.” Just like in OPA, but using a different approach, you can also push

- 3) Keycloak has taken an example of “Pet owners can access their own pet’s profiles.” and said we can write policies saying that "Only Owner" can access "/api/petservice/pet/{id}". But how does the policy engine figure out who is the owner of /pet/2 vs /pet/3?

4) Similarly, an OPA blog https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... gives the example where “Only the treating veterinarian is allowed to read a pet’s profile, and only when signed in from a device at the pet’s clinic”. Again, it is easy enough to provide the OPA engine the target pet and the current device location, but how exactly is it determined who is the treating veterinarian of that pet and what clinic the pet belongs to?

see/do in a particular feature, so how exactly would a policy engine bring back a subset of records that particular user can see (based on their affiliated company, etc.)? 6) Similarly, how exactly would a policy engine bring back all records but not the fields a user should not see (such as employee salary field, unless the user is a HR VIP)? These last two could be likened to @PostAuth post-filtering in spring security.

Rob Byrd DST Solutions Lead SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 t: (816) 435-7286 *| *m (816) 509-0119 *rmbyrd(a)dstsystems.com <rmbyrd(a)dstsystems.com&gt;* | *www.ssctech.com <http://www.ssctech.com/>* Follow us: [image: cid:image001.png@01D412C1.A14C5770] <https://www.linkedin.com/company/ss-c-technologies/> | [image: cid:image002.png@01D412C1.A14C5770] <https://twitter.com/ssctechnologies> | [image: cid:image003.png@01D412C1.A14C5770] <https://www.facebook.com/ssctechnologies/> *From:* Pedro Igor Silva [mailto:psilva@redhat.com] *Sent:* Thursday, November 8, 2018 6:42 AM *To:* Dmitry Telegin <dt(a)acutus.pro&gt; *Cc:* Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user < keycloak-user(a)lists.jboss.org&gt; *Subject:* Re: [keycloak-user] Data filtering in SQL Hi Dmitry, Agree with you when you mention application vs data security. I also agree that Keycloak can also solve data security problems. Privacy is one of the main reasons behind our UMA support a very important aspect of data security. In addition to privacy, we also added extensions to UMA and OAuth2 standards to enable applications to use Keycloak as a Policy Decision Point, mainly target for application security. As PDP (and PAP), Keycloak allows you to govern access to protected resources and to obtain authorization decisions as a result of the evaluation of policies associated with these resources. Being based on UMA and OAuth2 we support token-based authorization but also access control based on the permissions granted by the server. So, yeah, it should be possible to filter data based on those permissions as well dynamically create WHERE clauses. My main concerns about data security are scalability and manageability, two aspects that are closely related to how much fine-grained you want to be. Like I said, in Keycloak you can protect a set of one or more resources as well as scope specific permissions, which can span access decisions for one or more resources. We are using data security when you enable permissions to users or groups, where results are filtered based on the evaluation of these permissions. Performance wise, evaluation is quite satisfactory, being the main challenges the trade-off between usability vs performance. Recently we had important changes to improve the performance of our token endpoint and policy evaluation engine and I think we can perform well when fetching permissions from the server for a set of one or more resources. I'm happy to discuss how we can leverage what we have for data security if the community is interested. Regards. Pedro Igor On Wed, Nov 7, 2018 at 8:47 PM Dmitry Telegin <dt(a)acutus.pro&gt; wrote: Hi Rob, On Tue, 2018-11-06 at 16:28 +0000, Byrd, Rob M wrote: > (Hope this is the correct way to reply - let me know if not) > > Thanks. So my concern is really with the whole idea that an Enterprise Application's security constraints could really be all implemented based on url-patterns, is that what you guys are thinking? Cannot speak for Keycloak guys, but will put in my 2¢ as an architect - URL-based (or rather resource-based) authorization covers only one aspect of the application security. Data filtering is equally important, but it's just another facet of the problem, and needs to be solved accordingly. Indeed, Keycloak doesn't provide OOTB any means for automatically limiting subsets of data shown to the user, as Keycloak has a completely different scope (namely Web SSO/IDM solution). However, you can still use Keycloak as a central warehouse for your security (meta)data, and use it the way you want. Like I said before, nothing stops you from defining some policies in Keycloak, then retrieving them and converting to a WHERE clause for your SQL/JPQL/NoSQL query. Speaking of NoSQL - this might be not directly relevant to your problem, but still interesting. A similar problem has surfaced in the discussion following my talk on Apache Sling + Keycloak [1] earlier this year; the central point was: "okay, we can have Keycloak path-based authorization in Sling, but how do we limit the content visible to the user?" That time we came up with some sort of hybrid solution, like path-based security + JCR ACLs and/or application-level rules; but now I think this might be something similar, like generating JCR's equivalent to the WHERE clause based on Keycloak policy definition. Just to make sure I understand the case, let's imagine: - there are users and groups (live in Keycloak); - there are, say, "projects" (live in business tier + DB); - there is a policy in Keycloak saying "projects should be accessible only to the members of the respective groups"; - based on that: - GET /projects/<project> should return 200 + representation if the user is a member of the group, 403 otherwise; - GET /projects should return the list of projects the current user has access to. Is this correct? [1] https://adapt.to/2018/en/schedule/modern-authentication-in-sling-with-ope... Cheers, Dmitry Telegin CTO, Acutus s.r.o. Keycloak Consulting and Training Pod lipami street 339/52, 130 00 Prague 3, Czech Republic +42 (022) 888-30-71 E-mail: info(a)acutus.pro > > For example, mostly a user can visit most features (urls) in an application, but it is the subset of things they can see/do within the feature that is the crux of the security issue - and it does not seem feasible to architect urls in such a way that they can be used as the key to security. Thoughts? > > Thanks! > > Rob Byrd > DST > Solutions Lead > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > t: (816) 435-7286 | m (816) 509-0119 > rmbyrd(a)dstsystems.com | www.ssctech.com > Follow us: | | > > -----Original Message----- > > From: Dmitry Telegin [mailto:dt@acutus.pro] > Sent: Friday, November 2, 2018 12:22 AM > > To: Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user(a)lists.jboss.org > Subject: Re: [keycloak-user] Data filtering in SQL > > Hello Rob, > > If I get it right, it's all about generating SQL WHERE clause from Keycloak policies? I think this is doable, as Keycloak has a well-defined object model for authorization policies, and it's easy to obtain policy definitions in JSON format. I think Pedro Igor will tell you more about that. > > You should pay attention to the following: > - there are differences in semantics between OPA and Keycloak policies. For example, Keycloak policies do not operate HTTP methods but rather use more generic notion of scopes; > - not every policy type can be easily converted to a WHERE clause. It should be trivial for User/Group/Role policies, but is virtually impossible for Script and Rules, as they are just blackboxes that evaluate to true or false. Unless of course your DBMS has a built-in JavaScript engine :) > > Good luck! > Dmitry Telegin > CTO, Acutus s.r.o. > Keycloak Consulting and Training > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic > +42 (022) 888-30-71 > E-mail: info(a)acutus.pro > > On Thu, 2018-11-01 at 21:39 +0000, Byrd, Rob M wrote: > > I am comparing OPA authorization to Keycloak - how could I enforce Keycloak policy in the SQL closest to the data for good performance, including returning subsets of lists? OPA discusses this at https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... . > > > > Thanks! > > > > Rob Byrd > > DST > > Solutions Lead > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > t: (816) 435-7286 | m (816) 509-0119 > > rmbyrd@dstsystems.com<mailto:rmbyrd@dstsystems.com> | www.ssctech.com<http://www.ssctech.com/>;; > > > > Follow us: [cid:image001.png@01D412C1.A14C5770] < https://www.linkedin.com/company/ss-c-technologies/> | [ cid:image002.png@01D412C1.A14C5770] <https://twitter.com/ssctechnologies > | [cid:image003.png@01D412C1.A14C5770] < https://www.facebook.com/ssctechnologies/> > > > > > > > > Please consider the environment before printing this email and any attachments. > > > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > Please consider the environment before printing this email and any attachments. > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user ------------------------------ Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.

Pedro, That is helping my understanding some, thank you. I understand your recommendations on dealing with separating the employee's Salary field in my example too. Please see follow-up questions below. String resource attributes statically in keycloak: 2.1) I had been thinking of Resource as a *type* of resource to this point not a specific instance. But now I don't see how your suggestion of basically using the resource attribute to store a foreign key (ie. pet's veterinarian) will work unless we are talking about each individual pet instance being a keycloak resource. Similarly it was mentioned pet 1 and pet 2 could have a meaningful Owner in keycloak, which again is making me think that *instances* are being suggested to store along with entity-relationships basically. So, should I instead be thinking of keycloak resources as storing single instances of items in our system?

2.2) This relatively static storage of resources plus extra attributes like foreign keys seems to basically push/duplicate our business model of data into keycloak, to some degree, correct? And the more keycloak needs to decide, the more gets duplicated into keycloak?

Push claims: 2.3) The push claim alternative seems to be having application logic fetch more context as needed for the permission evaluation. This might work okay when going after a single entity or asking singular questions of the application logic – but for lists, such as a user seeing his list of 100 transaction history records amongst the 1 million transaction history records on the system, would a question be asked for each of the 1 million records, one at a time?

Post-filtering of records: 2.4) A use case I still seek clarification on is the "post-filtering of records", which I was trying to get at with my previous question #5. Stated in another way - say a financial database has 1 million transaction records across thousands of users. Every user is allowed to see transaction history records view, but only the ones they transacted. So, a single user viewing all transactions of the transaction history feature/resource should (obviously) only be able to see all HIS transactions, not all 1 million on the database. Spring Security would have @PostAuth for this (though its drawback is slow db performance on first query that does a db table scan and brings back everything to the middle tier, which then inefficiently whittles it down to just what pertains to the user). My question is what ways would this post-filtering of records be handled in Keycloak? With what I know so far, I am guessing at keycloak basic options: a) Have each of 1mil transaction records managed by Keycloak, add a "creator" attribute for who instigated the transaction, and have that user identifier stored on each record so Keycloak can do the filtering down to the 100 correct records

indicating who the "creator" is, so it may be matched against the current user and thus filter down to the 100 correct records c) During evaluation, the policy engine can call out to a service somewhere to get the primary keys of the subset of records this user can see (this may be like a Claim Information Point), then whittle the full list down to just those matching primary keys (kind of like sending an IN list of primary keys in a SQL WHERE clause) d) Something more like the “partial evaluation” that OPA blog and Dmitry has been talking about

General: 2.5) In general, it seems to me the bigger the chunks of extra context provided by application logic to the policy engine, the less detail about the actual constraints being enforced you have controlled and visible in the policy layer… somewhat defeating the purpose of the policy layer. Does that sound correct? I could see us offloading a ton of detail to the push claims – rather than, say, duplicating more of our business model in keycloak – and then realizing very little of our actual policy permission details are visible or controllable in the policy layer. So I am not sure what we are getting at that point. a) An answer might be drawing the line at only role-based access control in the policy layer since that affinity is more easily provided as input (thought that could even be debated) b) Maybe we try to define and draw the line at “resource-based” controls only in the policy layer c) Maybe we make the unit of work for each push claim so granular that truly all of the policy rules that are occurring are basically expressed in the policy layer (thus allowing control, flexibility and visibility in one consolidated place) Thanks for your time. Rob Byrd DST Solutions Lead SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 t: (816) 435-7286 *| *m (816) 509-0119 *rmbyrd(a)dstsystems.com <rmbyrd(a)dstsystems.com&gt;* | *www.ssctech.com <http://www.ssctech.com/>* Follow us: [image: cid:image001.png@01D412C1.A14C5770] <https://www.linkedin.com/company/ss-c-technologies/> | [image: cid:image002.png@01D412C1.A14C5770] <https://twitter.com/ssctechnologies> | [image: cid:image003.png@01D412C1.A14C5770] <https://www.facebook.com/ssctechnologies/> *From:* Pedro Igor Silva [mailto:psilva@redhat.com] *Sent:* Thursday, November 8, 2018 2:20 PM *To:* Byrd, Rob M <rmbyrd(a)dstsystems.com&gt; *Cc:* Dmitry Telegin <dt(a)acutus.pro>; keycloak-user < keycloak-user(a)lists.jboss.org&gt; *Subject:* Re: [keycloak-user] Data filtering in SQL On Thu, Nov 8, 2018 at 5:44 PM Byrd, Rob M <rmbyrd(a)dstsystems.com&gt; wrote: Thanks Dmitry and Pedro, Pardon my simple-minded response below, but I am wondering how these specific items would work? Dmitry, yes I agree your GET /projects/<project> and GET /projects scenario is on point for the issue – I hope my questions below can further clarify the discussion. Here, I will have to make a “go or no-go” decision in about a week. J I would love to take on the challenge of searching for the “holy grail” in this, but atm will need to figure out what Keycloak (or OPA, etc.) can confidently do today. Thanks for the great discussion and continued help! Questions 1) Simple role-based authorization policy seems doable. - Ex: “Only veterinarians are allowed to read pet profiles.” 2) But how to answer once more context is needed, such as one resource’s affinity to another? Literally how does the application figure it out? Like the below example would need a pet-veterinarian mapping resolved somehow, it seems: - “Only the treating veterinarian is allowed to read a pet’s profile.” Just like in OPA, but using a different approach, you can also push information (the input in OPA) to your policies. We call this "pushing claims" [1]. In our policy enforcer we also have the concept of a Claim Information Point [2] (similar concent as a PIP) which you can configure to automatically push claims to your policies when checking access for a particular resource. There is also a CIP that allows you to fetch claims from external services. Besides, a resource in Keycloak has attributes, which can be anything you want. So you could, for instance, have a Pet Foo resources in Keycloak and update a "veterinarian" attribute associated with it. So you could have a policy that checks if the user making the request is the same defined in the attribute. [1] https://www.keycloak.org/docs/latest/authorization_services/index.html#_s... [2] https://www.keycloak.org/docs/latest/authorization_services/index.html#_e... - 3) Keycloak has taken an example of “Pet owners can access their own pet’s profiles.” and said we can write policies saying that "Only Owner" can access "/api/petservice/pet/{id}". But how does the policy engine figure out who is the owner of /pet/2 vs /pet/3? I can think two options. Like I mentioned before, we are resource-based and resources have an owner. So you can write policies that check if the resource owner is the user making the authorization request. Another option is to push claims. 4) Similarly, an OPA blog https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... gives the example where “Only the treating veterinarian is allowed to read a pet’s profile, and only when signed in from a device at the pet’s clinic”. Again, it is easy enough to provide the OPA engine the target pet and the current device location, but how exactly is it determined who is the treating veterinarian of that pet and what clinic the pet belongs to? 5) In general, the security difficulty is constraining what a user can see/do in a particular feature, so how exactly would a policy engine bring back a subset of records that particular user can see (based on their affiliated company, etc.)? 6) Similarly, how exactly would a policy engine bring back all records but not the fields a user should not see (such as employee salary field, unless the user is a HR VIP)? These last two could be likened to @PostAuth post-filtering in spring security. You can have all those resources protected by Keycloak and make authorization requests to obtain the resources a user has access. We provide a REST API to create resources. And that is the point I tried to make when I said that data security is not really among the use cases we are trying to solve. Although it is possible. Keycloak allows you to send a "give me all" permission request. That means returning permissions for any resource, managed by Keycloak, that an user can access. But yeah, depending on how many resources you have you may end up with a huge response and a bad performance. Another approach is define a single Employee resource with a Salary scope to represent all your employees. So you could enforce access to your real employees and their salary based on the decisions made by the server for this single resource. The decision for one approach or another really depends on how fine grained you want to be, like I mentioned before. Do you need to manage indivudual employees or they all share the same access policies ? See this https://github.com/keycloak/keycloak-quickstarts/tree/master/app-authz-re... . Regarding fields (e.g: salary) you could consider it as a scope associated with a resource. In Keycloak you can define permissions for scopes, not only for resources. Rob Byrd DST Solutions Lead SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 t: (816) 435-7286 *| *m (816) 509-0119 *rmbyrd(a)dstsystems.com <rmbyrd(a)dstsystems.com&gt;* | *www.ssctech.com <http://www.ssctech.com/>* Follow us: [image: cid:image001.png@01D412C1.A14C5770] <https://www.linkedin.com/company/ss-c-technologies/> | [image: cid:image002.png@01D412C1.A14C5770] <https://twitter.com/ssctechnologies> | [image: cid:image003.png@01D412C1.A14C5770] <https://www.facebook.com/ssctechnologies/> *From:* Pedro Igor Silva [mailto:psilva@redhat.com] *Sent:* Thursday, November 8, 2018 6:42 AM *To:* Dmitry Telegin <dt(a)acutus.pro&gt; *Cc:* Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user < keycloak-user(a)lists.jboss.org&gt; *Subject:* Re: [keycloak-user] Data filtering in SQL Hi Dmitry, Agree with you when you mention application vs data security. I also agree that Keycloak can also solve data security problems. Privacy is one of the main reasons behind our UMA support a very important aspect of data security. In addition to privacy, we also added extensions to UMA and OAuth2 standards to enable applications to use Keycloak as a Policy Decision Point, mainly target for application security. As PDP (and PAP), Keycloak allows you to govern access to protected resources and to obtain authorization decisions as a result of the evaluation of policies associated with these resources. Being based on UMA and OAuth2 we support token-based authorization but also access control based on the permissions granted by the server. So, yeah, it should be possible to filter data based on those permissions as well dynamically create WHERE clauses. My main concerns about data security are scalability and manageability, two aspects that are closely related to how much fine-grained you want to be. Like I said, in Keycloak you can protect a set of one or more resources as well as scope specific permissions, which can span access decisions for one or more resources. We are using data security when you enable permissions to users or groups, where results are filtered based on the evaluation of these permissions. Performance wise, evaluation is quite satisfactory, being the main challenges the trade-off between usability vs performance. Recently we had important changes to improve the performance of our token endpoint and policy evaluation engine and I think we can perform well when fetching permissions from the server for a set of one or more resources. I'm happy to discuss how we can leverage what we have for data security if the community is interested. Regards. Pedro Igor On Wed, Nov 7, 2018 at 8:47 PM Dmitry Telegin <dt(a)acutus.pro&gt; wrote: Hi Rob, On Tue, 2018-11-06 at 16:28 +0000, Byrd, Rob M wrote: > (Hope this is the correct way to reply - let me know if not) > > Thanks. So my concern is really with the whole idea that an Enterprise Application's security constraints could really be all implemented based on url-patterns, is that what you guys are thinking? Cannot speak for Keycloak guys, but will put in my 2¢ as an architect - URL-based (or rather resource-based) authorization covers only one aspect of the application security. Data filtering is equally important, but it's just another facet of the problem, and needs to be solved accordingly. Indeed, Keycloak doesn't provide OOTB any means for automatically limiting subsets of data shown to the user, as Keycloak has a completely different scope (namely Web SSO/IDM solution). However, you can still use Keycloak as a central warehouse for your security (meta)data, and use it the way you want. Like I said before, nothing stops you from defining some policies in Keycloak, then retrieving them and converting to a WHERE clause for your SQL/JPQL/NoSQL query. Speaking of NoSQL - this might be not directly relevant to your problem, but still interesting. A similar problem has surfaced in the discussion following my talk on Apache Sling + Keycloak [1] earlier this year; the central point was: "okay, we can have Keycloak path-based authorization in Sling, but how do we limit the content visible to the user?" That time we came up with some sort of hybrid solution, like path-based security + JCR ACLs and/or application-level rules; but now I think this might be something similar, like generating JCR's equivalent to the WHERE clause based on Keycloak policy definition. Just to make sure I understand the case, let's imagine: - there are users and groups (live in Keycloak); - there are, say, "projects" (live in business tier + DB); - there is a policy in Keycloak saying "projects should be accessible only to the members of the respective groups"; - based on that: - GET /projects/<project> should return 200 + representation if the user is a member of the group, 403 otherwise; - GET /projects should return the list of projects the current user has access to. Is this correct? [1] https://adapt.to/2018/en/schedule/modern-authentication-in-sling-with-ope... Cheers, Dmitry Telegin CTO, Acutus s.r.o. Keycloak Consulting and Training Pod lipami street 339/52, 130 00 Prague 3, Czech Republic +42 (022) 888-30-71 E-mail: info(a)acutus.pro > > For example, mostly a user can visit most features (urls) in an application, but it is the subset of things they can see/do within the feature that is the crux of the security issue - and it does not seem feasible to architect urls in such a way that they can be used as the key to security. Thoughts? > > Thanks! > > Rob Byrd > DST > Solutions Lead > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > t: (816) 435-7286 | m (816) 509-0119 > rmbyrd(a)dstsystems.com | www.ssctech.com > Follow us: | | > > -----Original Message----- > > From: Dmitry Telegin [mailto:dt@acutus.pro] > Sent: Friday, November 2, 2018 12:22 AM > > To: Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user(a)lists.jboss.org > Subject: Re: [keycloak-user] Data filtering in SQL > > Hello Rob, > > If I get it right, it's all about generating SQL WHERE clause from Keycloak policies? I think this is doable, as Keycloak has a well-defined object model for authorization policies, and it's easy to obtain policy definitions in JSON format. I think Pedro Igor will tell you more about that. > > You should pay attention to the following: > - there are differences in semantics between OPA and Keycloak policies. For example, Keycloak policies do not operate HTTP methods but rather use more generic notion of scopes; > - not every policy type can be easily converted to a WHERE clause. It should be trivial for User/Group/Role policies, but is virtually impossible for Script and Rules, as they are just blackboxes that evaluate to true or false. Unless of course your DBMS has a built-in JavaScript engine :) > > Good luck! > Dmitry Telegin > CTO, Acutus s.r.o. > Keycloak Consulting and Training > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic > +42 (022) 888-30-71 > E-mail: info(a)acutus.pro > > On Thu, 2018-11-01 at 21:39 +0000, Byrd, Rob M wrote: > > I am comparing OPA authorization to Keycloak - how could I enforce Keycloak policy in the SQL closest to the data for good performance, including returning subsets of lists? OPA discusses this at https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... . > > > > Thanks! > > > > Rob Byrd > > DST > > Solutions Lead > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > t: (816) 435-7286 | m (816) 509-0119 > > rmbyrd@dstsystems.com<mailto:rmbyrd@dstsystems.com> | www.ssctech.com<http://www.ssctech.com/>;; > > > > Follow us: [cid:image001.png@01D412C1.A14C5770] < https://www.linkedin.com/company/ss-c-technologies/> | [ cid:image002.png@01D412C1.A14C5770] <https://twitter.com/ssctechnologies > | [cid:image003.png@01D412C1.A14C5770] < https://www.facebook.com/ssctechnologies/> > > > > > > > > Please consider the environment before printing this email and any attachments. > > > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > Please consider the environment before printing this email and any attachments. > > This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user ------------------------------ Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system. ------------------------------ Please consider the environment before printing this email and any attachments. This e-mail and any attachments are intended only for the individual or company to which it is addressed and may contain information which is privileged, confidential and prohibited from disclosure or unauthorized use under applicable law. If you are not the intended recipient of this e-mail, you are hereby notified that any use, dissemination, or copying of this e-mail or the information contained in this e-mail is strictly prohibited by the sender. If you have received this transmission in error, please return the material received to the sender and delete all copies from your system.

Pedro, I followed this thread with interest and have implemented your recommendation to do data filtering via added claims. Do you know if it's possible to add a JSON object to the claim? When I do permission.addClaim('data.filter.userId', {"a":5}); I get: "data.filter": ["[object Object]"] The protocol mapper scripting engine does allow adding JSON objects correctly. Regards, Geoffrey Cleaves On Fri, 9 Nov 2018 at 13:37, Pedro Igor Silva <psilva(a)redhat.com&gt; wrote: > On Thu, Nov 8, 2018 at 9:27 PM Byrd, Rob M <rmbyrd(a)dstsystems.com&gt; wrote: > > > Pedro, > > > > > > > > That is helping my understanding some, thank you. I understand your > > recommendations on dealing with separating the employee's Salary field > in > > my example too. Please see follow-up questions below. > > > > > > > > String resource attributes statically in keycloak: > > > > 2.1) I had been thinking of Resource as a *type* of resource to this > > point not a specific instance. But now I don't see how your suggestion > of > > basically using the resource attribute to store a foreign key (ie. pet's > > veterinarian) will work unless we are talking about each individual pet > > instance being a keycloak resource. Similarly it was mentioned pet 1 > and > > pet 2 could have a meaningful Owner in keycloak, which again is making > me > > think that *instances* are being suggested to store along with > > entity-relationships basically. So, should I instead be thinking of > > keycloak resources as storing single instances of items in our system? > > > You should not think of Keycloak as storing *only* single instances, but > with the necessary support to store single instances. That was my point > when I mentioned that you can have a 1:1 or 1:N mapping between keycloak > resources and your resources. > > The work to manage resources in Keycloak is quite trivial, keep them in > sync with your real resources too. Performance of authorization requests > for specific resources is quite good. It is a trade-off, the flexibility > we > give regarding governing access to individual resources vs the drawbacks > of > managing these resources in Keycloak. But again, you are not forced to use > this approach, it really depends on your requirements. For instance, we > support privacy through User-Managed Access (UMA), users are allowed to > manage permissions for their own resources, share resources with others, > allow/approve access to specific scopes/actions, and revoke access, where > you have loosely coupled clients and resource servers, resource servers in > control over the context that a permission should be granted, etc. > > I'm not pushing you to any specific solution but trying to clarify what we > have, what we can do, what we can improve and how we could help "data > filtering" use cases. Btw, thanks you and Dmitry for starting this. > > > 2.2) This relatively static storage of resources plus extra attributes > > like foreign keys seems to basically push/duplicate our business model > of > > data into keycloak, to some degree, correct? And the more keycloak > needs > > to decide, the more gets duplicated into keycloak? > > > Not really, but true for data filtering. That is another > point/drawback/concern that I tried to make when I said that data > filtering > is not among our target use cases. We can support it, but not something we > discussed in the details like we are doing in this thread. > > Attributes can be used to define specific security related data associated > with a resource which are not part of your business model. Thus, allowing > you to keep your business model decoupled from security aspects that > govern > access to your resources. > > > > > > > Push claims: > > > > 2.3) The push claim alternative seems to be having application logic > fetch > > more context as needed for the permission evaluation. This might work > okay > > when going after a single entity or asking singular questions of the > > application logic – but for lists, such as a user seeing his list of 100 > > transaction history records amongst the 1 million transaction history > > records on the system, would a question be asked for each of the 1 > million > > records, one at a time? > > > Pushing claims is not the correct approach to solve this problem. > > First, Keycloak is optmized to only evaluate policies for resources where > the subject is the owner. So, considering that I decided to manage all 1 > million resources in Keycloak, each resource would have a user as the > resource owner. During evaluation the policy engine is going to evaluate > permissions fo 100 resources, not 1 million. > > You may ask now, would that scale ? Depends on how you obtain permissions > from the server. If you are asking the server for all permissions and > users > can have 1 million resources over time, it won't scale. However, if you > ask > permissions for individual transactions or a small set of transactions, it > will scale. > > > > > > > Post-filtering of records: > > > > 2.4) A use case I still seek clarification on is the "post-filtering of > > records", which I was trying to get at with my previous question #5. > > Stated in another way - say a financial database has 1 million > transaction > > records across thousands of users. Every user is allowed to see > transaction > > history records view, but only the ones they transacted. So, a single > user > > viewing all transactions of the transaction history feature/resource > should > > (obviously) only be able to see all HIS transactions, not all 1 million > on > > the database. Spring Security would have @PostAuth for this (though its > > drawback is slow db performance on first query that does a db table scan > > and brings back everything to the middle tier, which then inefficiently > > whittles it down to just what pertains to the user). My question is > what > > ways would this post-filtering of records be handled in Keycloak? With > > what I know so far, I am guessing at keycloak basic options: > > > > a) Have each of 1mil transaction records managed by Keycloak, add a > > "creator" attribute for who instigated the transaction, and have that > user > > identifier stored on each record so Keycloak can do the filtering down > to > > the 100 correct records > > > b) Receive a push claim, for each of the 1mil transaction records, > > indicating who the "creator" is, so it may be matched against the > current > > user and thus filter down to the 100 correct records > > > > c) During evaluation, the policy engine can call out to a service > > somewhere to get the primary keys of the subset of records this user can > > see (this may be like a Claim Information Point), then whittle the full > > list down to just those matching primary keys (kind of like sending an > IN > > list of primary keys in a SQL WHERE clause) > > > > d) Something more like the “partial evaluation” that OPA blog and Dmitry > > has been talking about > > > You don't need to create a "creator" attribute. Resources in Keycloak > always have a owner. It can be the resource server (the application) > itself > or some user in your realm. See > > https://www.keycloak.org/docs/latest/authorization_services/index.html#_r... > . > > I just realized that we have another option in Keycloak that might be > helpful to solve data filtering. I think it is similar to what you linked > from OPA docs. Some background first about the capability that may help > with that. > > In Keycloak, policies are allowed to push back claims to resource server > (the application protecting the resources you want to access). Quite > similar to Advice/Obligation in XACML. The idea is push back additional > constratins to the application in order to indicate additional checks that > should be performed by the policy enforcer. As a note, our CIPs do that in > order to reinforce access to resources based on any claim pushed to > Keycloak when evaluating permissions. > > Let me give you an example. Consider a Transaction resource that you > created in Keycloak. This is a generic resource representing all your > transactions. Suppose you have a specific scope that represents an > operation that lists all user transactions. Let's call this scope > "transaction:list". This scope is associated with the Transaction > resource. > So you have: > > Resource: Transaction > Scopes: transaction:list > > Now, in addition to any other policy that applies to the Transaction > resource (role, group, whatever) you have a specific permissions that > govern access to the "transaction:list" scope. This permissions is granted > by a "List Transaction Policy" as follows: > > var permission = $evaluation.getPermission(); > var identity = $evaluation.getContext().getIdentity(); > > permission.addClaim('data.filter.userId', identity.getId()); > > $evaluation.grant(); > > Now, the client application acting on behalf of your user tries to access > your application at "/api/v1/transaction" using HTTP GET. You know that > GET > method on that endpoint is associated with the "transaction:list" scope, > so > you ask Keycloak for permissions to "Transaction" resources + > "transaction:list" scope. > > As a result, Keycloak will give you a response as follows: > > "permissions": [ > { > "scopes": [ > "album:list" > ], > "claims": { > "data.filter.userId": [ > "e68fa92d-6167-438f-844b-78c7abfc0dd2" > ] > }, > "rsid": "d3aaaf68-50cf-4c5c-97b9-99910a7bfb27", > "rsname": "Transaction Resource" > } > ] > > In your application you can use the permission granted above, and the > "data.filter.userId" claim to create a query in your database as follows: > > StringBuilder filter = new StringBuilder(); > Map<String, Object> queryParams = new HashMap<String, Object>(); > > for (Map.Entry<String, Set<String>> entry : > permission.getClaims().entrySet()) { > > if (filter.length() != 0) { > filter.append(" and "); > } > > String key = entry.getKey(); > > if (key.startsWith("data.filter")) { > String left = key.substring(key.lastIndexOf('.') + 1); > filter.append(left).append(" = :").append(left); > queryParams.put(left, entry.getValue()); > } > }; > > Query query = this.entityManager.createQuery("from Transaction where " > + filter.toString()); > > for (Map.Entry<String, Object> entry : queryParams.entrySet()) { > query.setParameter(entry.getKey(), entry.getValue()); > } > > The key points here are: > > * You are using a single resource to represent all transactions in your > system > > * You are using a specific policy to protect the "transaction:list" > operation by pushing back to your application how access should be > enforced > > * Access management is still centralized and you can push back the > "data.filter" claim with any information you want in order to indicate > to the application how data must be filtered > > * Your policies are using information already available from the > eluvation context (like user id, user attributes, user roles, groups) > without being forced to push any claim to the server > > In fact, I can use this in one of our quickstarts that is using a > database and protecting data. So we could introduce something similar > to this in order to filter recors in addition to protect API > endpoints. > > How that sounds to you ? > > > > > > General: > > > > 2.5) In general, it seems to me the bigger the chunks of extra context > > provided by application logic to the policy engine, the less detail > about > > the actual constraints being enforced you have controlled and visible in > > the policy layer… somewhat defeating the purpose of the policy layer. > Does > > that sound correct? I could see us offloading a ton of detail to the > push > > claims – rather than, say, duplicating more of our business model in > > keycloak – and then realizing very little of our actual policy > permission > > details are visible or controllable in the policy layer. So I am not > sure > > what we are getting at that point. > > > > a) An answer might be drawing the line at only > role-based > > access control in the policy layer since that affinity is more easily > > provided as input (thought that could even be debated) > > > > b) Maybe we try to define and draw the line at > > “resource-based” controls only in the policy layer > > > > c) Maybe we make the unit of work for each push claim so > > granular that truly all of the policy rules that are occurring are > > basically expressed in the policy layer (thus allowing control, > flexibility > > and visibility in one consolidated place) > > > > > > > > Thanks for your time. > > > > > > > > Rob Byrd > > > > DST > > > > Solutions Lead > > > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > > > t: (816) 435-7286 *| *m (816) 509-0119 > > > > *rmbyrd(a)dstsystems.com <rmbyrd(a)dstsystems.com&gt;* | *www.ssctech.com > > <http://www.ssctech.com/>* > > > > Follow us: [image: cid:image001.png@01D412C1.A14C5770] > > <https://www.linkedin.com/company/ss-c-technologies/> | [image: > > cid:image002.png@01D412C1.A14C5770] < > https://twitter.com/ssctechnologies> | > > [image: cid:image003.png@01D412C1.A14C5770] > > <https://www.facebook.com/ssctechnologies/> > > > > > > > > *From:* Pedro Igor Silva [mailto:psilva@redhat.com] > > *Sent:* Thursday, November 8, 2018 2:20 PM > > *To:* Byrd, Rob M <rmbyrd(a)dstsystems.com&gt; > > *Cc:* Dmitry Telegin <dt(a)acutus.pro>; keycloak-user < > > keycloak-user(a)lists.jboss.org&gt; > > *Subject:* Re: [keycloak-user] Data filtering in SQL > > > > > > > > > > > > On Thu, Nov 8, 2018 at 5:44 PM Byrd, Rob M <rmbyrd(a)dstsystems.com&gt; > wrote: > > > > Thanks Dmitry and Pedro, > > > > > > > > Pardon my simple-minded response below, but I am wondering how these > > specific items would work? Dmitry, yes I agree your GET > > /projects/<project> and GET /projects scenario is on point for the > issue – > > I hope my questions below can further clarify the discussion. Here, I > will > > have to make a “go or no-go” decision in about a week. J I would love > to > > take on the challenge of searching for the “holy grail” in this, but atm > > will need to figure out what Keycloak (or OPA, etc.) can confidently do > > today. > > > > > > > > Thanks for the great discussion and continued help! > > > > > > > > Questions > > > > 1) Simple role-based authorization policy seems doable. > > > > - Ex: “Only veterinarians are allowed to read pet profiles.” > > > > > > > > 2) But how to answer once more context is needed, such as one resource’s > > affinity to another? Literally how does the application figure it out? > > Like the below example would need a pet-veterinarian mapping resolved > > somehow, it seems: > > > > - “Only the treating veterinarian is allowed to read a pet’s > profile.” > > > > Just like in OPA, but using a different approach, you can also push > > information (the input in OPA) to your policies. We call this "pushing > > claims" [1]. In our policy enforcer we also have the concept of a Claim > > Information Point [2] (similar concent as a PIP) which you can > configure to > > automatically push claims to your policies when checking access for a > > particular resource. There is also a CIP that allows you to fetch claims > > from external services. > > > > > > > > Besides, a resource in Keycloak has attributes, which can be anything > you > > want. So you could, for instance, have a Pet Foo resources in Keycloak > and > > update a "veterinarian" attribute associated with it. So you could have > a > > policy that checks if the user making the request is the same defined in > > the attribute. > > > > > > > > [1] > > > https://www.keycloak.org/docs/latest/authorization_services/index.html#_s... > > > > [2] > > > https://www.keycloak.org/docs/latest/authorization_services/index.html#_e... > > > > > > > > > > - > > > > > > > > 3) Keycloak has taken an example of “Pet owners can access their own > pet’s > > profiles.” and said we can write policies saying that "Only Owner" can > > access "/api/petservice/pet/{id}". But how does the policy engine > figure > > out who is the owner of /pet/2 vs /pet/3? > > > > I can think two options. Like I mentioned before, we are resource-based > > and resources have an owner. So you can write policies that check if the > > resource owner is the user making the authorization request. Another > option > > is to push claims. > > > > 4) Similarly, an OPA blog > > > https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... > > gives the example where “Only the treating veterinarian is allowed to > read > > a pet’s profile, and only when signed in from a device at the pet’s > > clinic”. Again, it is easy enough to provide the OPA engine the target > pet > > and the current device location, but how exactly is it determined who is > > the treating veterinarian of that pet and what clinic the pet belongs > to? > > > > 5) In general, the security difficulty is constraining what a user can > > see/do in a particular feature, so how exactly would a policy engine > bring > > back a subset of records that particular user can see (based on their > > affiliated company, etc.)? > > > > 6) Similarly, how exactly would a policy engine bring back all records > but > > not the fields a user should not see (such as employee salary field, > unless > > the user is a HR VIP)? These last two could be likened to @PostAuth > > post-filtering in spring security. > > > > You can have all those resources protected by Keycloak and make > > authorization requests to obtain the resources a user has access. We > > provide a REST API to create resources. And that is the point I tried to > > make when I said that data security is not really among the use cases we > > are trying to solve. Although it is possible. Keycloak allows you to > send a > > "give me all" permission request. That means returning permissions for > any > > resource, managed by Keycloak, that an user can access. But yeah, > depending > > on how many resources you have you may end up with a huge response and a > > bad performance. > > > > > > > > Another approach is define a single Employee resource with a Salary > scope > > to represent all your employees. So you could enforce access to your > real > > employees and their salary based on the decisions made by the server for > > this single resource. > > > > > > > > The decision for one approach or another really depends on how fine > > grained you want to be, like I mentioned before. Do you need to manage > > indivudual employees or they all share the same access policies ? > > > > > > > > See this > > > https://github.com/keycloak/keycloak-quickstarts/tree/master/app-authz-re... > > . > > > > > > > > Regarding fields (e.g: salary) you could consider it as a scope > > associated with a resource. In Keycloak you can define permissions for > > scopes, not only for resources. > > > > > > > > > > > > Rob Byrd > > > > DST > > > > Solutions Lead > > > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > > > t: (816) 435-7286 *| *m (816) 509-0119 > > > > *rmbyrd(a)dstsystems.com <rmbyrd(a)dstsystems.com&gt;* | *www.ssctech.com > > <http://www.ssctech.com/>* > > > > Follow us: [image: cid:image001.png@01D412C1.A14C5770] > > <https://www.linkedin.com/company/ss-c-technologies/> | [image: > > cid:image002.png@01D412C1.A14C5770] < > https://twitter.com/ssctechnologies> | > > [image: cid:image003.png@01D412C1.A14C5770] > > <https://www.facebook.com/ssctechnologies/> > > > > > > > > *From:* Pedro Igor Silva [mailto:psilva@redhat.com] > > *Sent:* Thursday, November 8, 2018 6:42 AM > > *To:* Dmitry Telegin <dt(a)acutus.pro&gt; > > *Cc:* Byrd, Rob M <rmbyrd(a)dstsystems.com>; keycloak-user < > > keycloak-user(a)lists.jboss.org&gt; > > *Subject:* Re: [keycloak-user] Data filtering in SQL > > > > > > > > Hi Dmitry, > > > > > > > > Agree with you when you mention application vs data security. I also > agree > > that Keycloak can also solve data security problems. > > > > > > > > Privacy is one of the main reasons behind our UMA support a very > important > > aspect of data security. In addition to privacy, we also added > extensions > > to UMA and OAuth2 standards to enable applications to use Keycloak as a > > Policy Decision Point, mainly target for application security. > > > > > > > > As PDP (and PAP), Keycloak allows you to govern access to protected > > resources and to obtain authorization decisions as a result of the > > evaluation of policies associated with these resources. Being based on > UMA > > and OAuth2 we support token-based authorization but also access control > > based on the permissions granted by the server. So, yeah, it should be > > possible to filter data based on those permissions as well dynamically > > create WHERE clauses. > > > > > > > > My main concerns about data security are scalability and manageability, > > two aspects that are closely related to how much fine-grained you want > to > > be. Like I said, in Keycloak you can protect a set of one or more > resources > > as well as scope specific permissions, which can span access decisions > for > > one or more resources. > > > > > > > > We are using data security when you enable permissions to users or > groups, > > where results are filtered based on the evaluation of these permissions. > > Performance wise, evaluation is quite satisfactory, being the main > > challenges the trade-off between usability vs performance. Recently we > had > > important changes to improve the performance of our token endpoint and > > policy evaluation engine and I think we can perform well when fetching > > permissions from the server for a set of one or more resources. > > > > > > > > I'm happy to discuss how we can leverage what we have for data security > if > > the community is interested. > > > > > > > > Regards. > > > > Pedro Igor > > > > > > > > On Wed, Nov 7, 2018 at 8:47 PM Dmitry Telegin <dt(a)acutus.pro&gt; wrote: > > > > Hi Rob, > > > > On Tue, 2018-11-06 at 16:28 +0000, Byrd, Rob M wrote: > > > (Hope this is the correct way to reply - let me know if not) > > > > > > Thanks. So my concern is really with the whole idea that an > Enterprise > > Application's security constraints could really be all implemented > based on > > url-patterns, is that what you guys are thinking? > > > > Cannot speak for Keycloak guys, but will put in my 2¢ as an architect - > > URL-based (or rather resource-based) authorization covers only one > aspect > > of the application security. Data filtering is equally important, but > it's > > just another facet of the problem, and needs to be solved accordingly. > > Indeed, Keycloak doesn't provide OOTB any means for automatically > limiting > > subsets of data shown to the user, as Keycloak has a completely > different > > scope (namely Web SSO/IDM solution). > > > > However, you can still use Keycloak as a central warehouse for your > > security (meta)data, and use it the way you want. Like I said before, > > nothing stops you from defining some policies in Keycloak, then > retrieving > > them and converting to a WHERE clause for your SQL/JPQL/NoSQL query. > > > > Speaking of NoSQL - this might be not directly relevant to your problem, > > but still interesting. A similar problem has surfaced in the discussion > > following my talk on Apache Sling + Keycloak [1] earlier this year; the > > central point was: "okay, we can have Keycloak path-based authorization > in > > Sling, but how do we limit the content visible to the user?" > > That time we came up with some sort of hybrid solution, like path-based > > security + JCR ACLs and/or application-level rules; but now I think this > > might be something similar, like generating JCR's equivalent to the > WHERE > > clause based on Keycloak policy definition. > > > > Just to make sure I understand the case, let's imagine: > > - there are users and groups (live in Keycloak); > > - there are, say, "projects" (live in business tier + DB); > > - there is a policy in Keycloak saying "projects should be accessible > only > > to the members of the respective groups"; > > - based on that: > > - GET /projects/<project> should return 200 + representation if the > user > > is a member of the group, 403 otherwise; > > - GET /projects should return the list of projects the current user has > > access to. > > > > Is this correct? > > > > [1] > > > https://adapt.to/2018/en/schedule/modern-authentication-in-sling-with-ope... > > > > Cheers, > > Dmitry Telegin > > CTO, Acutus s.r.o. > > Keycloak Consulting and Training > > > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic > > +42 (022) 888-30-71 > > E-mail: info(a)acutus.pro > > > > > > > > For example, mostly a user can visit most features (urls) in an > > application, but it is the subset of things they can see/do within the > > feature that is the crux of the security issue - and it does not seem > > feasible to architect urls in such a way that they can be used as the > key > > to security. Thoughts? > > > > > > Thanks! > > > > > > Rob Byrd > > > DST > > > Solutions Lead > > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > > t: (816) 435-7286 | m (816) 509-0119 > > > rmbyrd(a)dstsystems.com | www.ssctech.com > > > Follow us: | | > > > > > > -----Original Message----- > > > > From: Dmitry Telegin [mailto:dt@acutus.pro] > > > Sent: Friday, November 2, 2018 12:22 AM > > > > To: Byrd, Rob M <rmbyrd(a)dstsystems.com>; > keycloak-user(a)lists.jboss.org > > > Subject: Re: [keycloak-user] Data filtering in SQL > > > > > > Hello Rob, > > > > > > If I get it right, it's all about generating SQL WHERE clause from > > Keycloak policies? I think this is doable, as Keycloak has a > well-defined > > object model for authorization policies, and it's easy to obtain policy > > definitions in JSON format. I think Pedro Igor will tell you more about > > that. > > > > > > You should pay attention to the following: > > > - there are differences in semantics between OPA and Keycloak > policies. > > For example, Keycloak policies do not operate HTTP methods but rather > use > > more generic notion of scopes; > > > - not every policy type can be easily converted to a WHERE clause. It > > should be trivial for User/Group/Role policies, but is virtually > impossible > > for Script and Rules, as they are just blackboxes that evaluate to true > or > > false. Unless of course your DBMS has a built-in JavaScript engine :) > > > > > > Good luck! > > > Dmitry Telegin > > > CTO, Acutus s.r.o. > > > Keycloak Consulting and Training > > > > > > Pod lipami street 339/52, 130 00 Prague 3, Czech Republic > > > +42 (022) 888-30-71 > > > E-mail: info(a)acutus.pro > > > > > > On Thu, 2018-11-01 at 21:39 +0000, Byrd, Rob M wrote: > > > > I am comparing OPA authorization to Keycloak - how could I enforce > > Keycloak policy in the SQL closest to the data for good performance, > > including returning subsets of lists? OPA discusses this at > > > https://blog.openpolicyagent.org/write-policy-in-opa-enforce-policy-in-sq... > > . > > > > > > > > Thanks! > > > > > > > > Rob Byrd > > > > DST > > > > Solutions Lead > > > > SS&C Technologies Inc. | 1055 Broadway, Kansas City, MO 64105 > > > > t: (816) 435-7286 | m (816) 509-0119 > > > > rmbyrd@dstsystems.com<mailto:rmbyrd@dstsystems.com> | > > www.ssctech.com<http://www.ssctech.com/>;; > > > > > > Follow us: [cid:image001.png@01D412C1.A14C5770] < > > https://www.linkedin.com/company/ss-c-technologies/> | [ > > cid:image002.png@01D412C1.A14C5770] < > https://twitter.com/ssctechnologies > > > | [cid:image003.png@01D412C1.A14C5770] < > > https://www.facebook.com/ssctechnologies/> > > > > > > > > > > > > > > > > Please consider the environment before printing this email and any > > attachments. > > > > > > > > This e-mail and any attachments are intended only for the individual > > or company to which it is addressed and may contain information which is > > privileged, confidential and prohibited from disclosure or unauthorized > use > > under applicable law. If you are not the intended recipient of this > e-mail, > > you are hereby notified that any use, dissemination, or copying of this > > e-mail or the information contained in this e-mail is strictly > prohibited > > by the sender. If you have received this transmission in error, please > > return the material received to the sender and delete all copies from > your > > system. > > > > _______________________________________________ > > > > keycloak-user mailing list > > > > keycloak-user(a)lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > > > > > > Please consider the environment before printing this email and any > > attachments. > > > > > > This e-mail and any attachments are intended only for the individual > or > > company to which it is addressed and may contain information which is > > privileged, confidential and prohibited from disclosure or unauthorized > use > > under applicable law. If you are not the intended recipient of this > e-mail, > > you are hereby notified that any use, dissemination, or copying of this > > e-mail or the information contained in this e-mail is strictly > prohibited > > by the sender. If you have received this transmission in error, please > > return the material received to the sender and delete all copies from > your > > system. > > _______________________________________________ > > keycloak-user mailing list > > keycloak-user(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > ------------------------------ > > > > Please consider the environment before printing this email and any > > attachments. > > > > This e-mail and any attachments are intended only for the individual or > > company to which it is addressed and may contain information which is > > privileged, confidential and prohibited from disclosure or unauthorized > use > > under applicable law. If you are not the intended recipient of this > e-mail, > > you are hereby notified that any use, dissemination, or copying of this > > e-mail or the information contained in this e-mail is strictly > prohibited > > by the sender. If you have received this transmission in error, please > > return the material received to the sender and delete all copies from > your > > system. > > > > ------------------------------ > > Please consider the environment before printing this email and any > > attachments. > > > > This e-mail and any attachments are intended only for the individual or > > company to which it is addressed and may contain information which is > > privileged, confidential and prohibited from disclosure or unauthorized > use > > under applicable law. If you are not the intended recipient of this > e-mail, > > you are hereby notified that any use, dissemination, or copying of this > > e-mail or the information contained in this e-mail is strictly > prohibited > > by the sender. If you have received this transmission in error, please > > return the material received to the sender and delete all copies from > your > > system. > > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user