11:44 p.m.
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...
<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
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.
