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