[keycloak-dev] user groups vs. client groups

[Stian Thorgersen]

+1 Let's all have a hangout when Pedro returns :)

On 23 November 2015 at 15:40, Bill Burke <bburke at redhat.com> wrote:

>
>
> On 11/23/2015 9:22 AM, Adam Young 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.
> >
>
> We really should have a BJ session.   Basic Java EE does permission via
> URL.  Pedro's stuff will be a lot more abstract.  You would submit your
> parameters (user, group, role, resource attributes, etc.) and get back
> authorization permissions.  All through the UMA protocol.  URL is just
> one type of resource in Pedro's stuff...Pedro should answer though.
> Stian and I really only have a high level understanding of what he is
> doing.
>
> >
> >     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;
>
> We don't know shit about the Python stack.  Personally I haven't touched
> Python in 15 years.  But anything Java based we have a good pulse on.
> We've focused mostly on basic Java EE authorization.  Most of our users
> are interested in Keycloak out of the box, or customizing the federation
> and/or authentication flows.
>
>
> > 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.
>
> Yes!  Let's figure something out.
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151123/6fc4ed45/attachment.html