10:04 p.m.
This not among the use cases we are trying to solve with Keycloak
Authorization Services.
But looking at one of the examples from that article:
“Pet owners can access their own pet’s profiles.”
“Veterinarians can access pet profiles from devices at the clinic.”
You could have the same behavior if you API is designed in a way that you
can enforce access to individual resources, in that case, the "pets". You
can write policies saying that "Only Owner" can access
"/api/petclinic/pet/{id}", as well make sure "Only Veterinarians" can
access certain pets.
You could even delegate to pet owners complete control over the permissions
that govern access to information about their pets by using UMA.
Note that we are resource-based, so you are basically telling Keycloak the
resources you are protecting. Where they can represent the actual resource
(e.g.: Pet Foo) or a generic resource representing a set of one or more
resources (e.g.: Pet). What I mean is that you are not forced to create a
resource in Keycloak for every single resource you want to protect, but
just a single resource representing all resources you are protecting. Of
course, as long as they share the same access policies.
Regards.
Pedro Igor
On Tue, Nov 6, 2018 at 2:38 PM Byrd, Rob M <rmbyrd(a)dstsystems.com> 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?
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