<div dir="ltr"><div>Pedro is currently away on holiday. I believe he's back in two weeks. We should have an early alpha ready for the authorization services shortly after he's back. You can check out the code at <a href="https://github.com/pedroigor/keycloak-authz">https://github.com/pedroigor/keycloak-authz</a>, but AFAIK it's not quite ready for consumption.</div><div><br></div><div>The aim of the alpha is to have something available for others to play with and to obtain feedback. It's still very much open to be discussed.</div><div><br></div><div>Your feedback would be very welcome, but we should wait until Pedro is back before we continue the discussion.</div><br><div class="gmail_extra"><br><div class="gmail_quote">On 23 November 2015 at 15:22, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span>On 11/22/2015 10:50 PM, Bill Burke wrote:<br>
> Most Java EE apps, simple permission stuff is handled by the<br>
> applications themselves. The security layer propagates identity and<br>
> user/role mappings and the application decides which roles have<br>
> permission to access which resource. So, Keycloak core can focus on<br>
> provide user/group/role/attribute authentication and information. The<br>
> service Pedro is working on will offer an optional, complimentary way to<br>
> centrally manage permissions if you want to. My on personal opinion is<br>
> that most apps will want to manage resource permissions in their own<br>
> special app-specific way and Pedro's stuff will be most useful as a<br>
> backend-service.<br>
</span>So the analogue in Keystone is the Policy stuff. Again, Keystone has<br>
had to weather a storm;<br>
<br>
Access Control permissions in OpenStack are done at the Python API (not<br>
URL) level. The code calls out to the policy API to check that the<br>
context of the call matches the attributes of the resource. Practically<br>
speaking, this means two checks: does the role match, and does the<br>
scope (project or user) match.<br>
<br>
<br>
It would be easier for deployers if it was URL based. Instead, it is<br>
deep in the code, and the reason being that often an application needs<br>
to fetch an object from the database to check ownership before checking<br>
scope (what project owns the resource). What we learned is that this<br>
can and should actually be two checks. The role check can be done in a<br>
non-application specific way, and performed in the middleware stack;<br>
kinda like in the Tomcat Webserver prior to hitting the servlet itself,<br>
but in a python WSGI way instead. This part could and should be<br>
dynamically fetched from the Keystone server. Only the scope check<br>
needs to be done in a resource specific way. There is support at the<br>
EJB/Hibernate layer for this kind of access control, too, and that may<br>
be a better place to focus on completely. I suspect it is this kind of<br>
"Dynamic Policy" stuff that Pedro is working on. Do we have docs for<br>
that? I'd love to compare notes.<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
I'm in the US, on East Coast time. THis is a short Week due to<br>
Thanksgiving, but I'd love to have a video conference of some sort the<br>
following week to sync up the lessons learned from both projects.<br>
<div><div>_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</div></div></blockquote></div><br></div></div>