[keycloak-dev] user groups vs. client groups

[Bill Burke]

I only speed read your response (I'll review again after thanksgiving), 
but I believe Hawkular has similar role/permission requirements.  As I 
said before, Keycloak is currently weak on authorization.  A User has 
Group Membership and Role mappings and attributes.  That's it right now. 
  How the application applies that security metadata is up to the app. 
Excited to talk to you though when Pedro gets back from vacation.



On 11/25/2015 12:01 PM, Adam Young wrote:
> On 11/23/2015 09:40 AM, Bill Burke 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.
>
> This is really not a Python issue, rather it is how OpenStack has
> evolved. People forked off the main project and cargo-culted in the
> Access control implementations: good, bad and Ugly.
>
> But the lesson learned is that there are two layers: URL based and
> underlying resource.  You can't count on the URL layer to properly
> protect access at the persistence layer.  You saw this reflected in J2EE
> way back with Servlet VS Entity-EJB protections, and the modern
> evolution of them as well.
>
> JEE/JPA seems to have a "Role" check as its basic level of control. What
> we've seen is this is only half of what we need.  THe role needs to be
> assigned on some collective aspect of ownership in order for the pattern
> to scale.
>
>
> Lets say that we are managing virtual machines.  There are three levels
> of VMs:  development, qe, production.
>
>
> If you say that anyone withthe "VM_MANAGER" role can create a VM, they
> will be able to create VMs for dev, qe, and production.  This is not
> what you want.  Instead:
>
>
> A Dev should be able to create a VM in Dev, view it in QE, not be to do
> anything in production
>
> A QE-Engineer should be able to create a VM in QE, view it in Dev, and
> not do anything in production
>
> Production Level VMs can only be managed by automated processes that are
> kicked off based on a quorum (at least 2 votes) of QE engineers.
>
> There are multiple Dev groups: AccountsReceivable, AccountsPayable,
> GeneraLedger, Tax.  Each can work within their own set of VMs only, but
> all must have the same set of rules.
>
>
> Within a development group,  there are a handful of roles: developers,
> DBa, Manager, QA (assigned over from the core QA org. These people can
> do various things to the VMs inside their own projects, but nothing
> inside the other dev groups.
>
>
>
> You get the idea.  The roles and access permissions need to be
> scalable.  It can't be one size fits all, and it can't be hardcoded.
>
>
> The general mechanism is a tuple:
>
>
> role,  actor, target.
>
>
> Role is a string that describes what the user can do.
> Actor is User or Group of users
> Target is the container for the resources.  In OpenStack, we have two:
> Projects and Domains, but this is a mistake, as we could have used
> Project for both.
>
>
> If you were managing Wordpress deployments, the roles would be:
>
> Administrator
> Editor
> Subscriber
> Author
> Contributor
>
> And the Target would be the actual instance:  and editor on one may be
> an author on another.
>
> The real power of this model comes in delegation.  You want to know who
> assigned what role to whom.
>
> In OpenStack, we are working toward a unified delegation model, that
> links short term delegations (Trusts and OAuth) with Role Assignments.
>
> This is up for review here:
> https://review.openstack.org/#/c/189816/15
>
> There is a real need to be able to assign identities to non-human
> entities, and to be able to delegate the appropriate permissions to
> them.  In FreeIPA, we are making more and more use of the Service
> principals to do that.
>
>
>
>>
>>
>>> 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.
>>
>>
>>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com