<div dir="ltr">+1 Let's all have a hangout when Pedro returns :)</div><div class="gmail_extra"><br><div class="gmail_quote">On 23 November 2015 at 15:40, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 11/23/2015 9:22 AM, Adam Young wrote:<br>
> 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>
> 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>
</span>We really should have a BJ session. Basic Java EE does permission via<br>
URL. Pedro's stuff will be a lot more abstract. You would submit your<br>
parameters (user, group, role, resource attributes, etc.) and get back<br>
authorization permissions. All through the UMA protocol. URL is just<br>
one type of resource in Pedro's stuff...Pedro should answer though.<br>
Stian and I really only have a high level understanding of what he is doing.<br>
<span class=""><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>
<br>
</span>We don't know shit about the Python stack. Personally I haven't touched<br>
Python in 15 years. But anything Java based we have a good pulse on.<br>
We've focused mostly on basic Java EE authorization. Most of our users<br>
are interested in Keycloak out of the box, or customizing the federation<br>
and/or authentication flows.<br>
<span class=""><br>
<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>
><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>
<br>
</span>Yes! Let's figure something out.<br>
<span class="im HOEnZb"><br>
<br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org">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>