Thanks everyone for your input. I generally agree that there is something that doesn't quite feel right about purely trusting this information to be passed from service to service, this is why i was keen for outside input and I have been rethinking the approach.
To this end i've proposed reservations (a name that doesn't feel right): https://review.openstack.org/#/c/330329/ At a gut feeling level i'm much happier with the concept. I think it will allow us to handle the distinction between user->service and service->service communication much better and has the added bonus of potentially opening up some policy options in future. Please let me know of any concerns/thoughts on the new approach. Once again i've only written the proposal part of the spec as there will be a lot of details to figure out if we go forward. It is also fairly rough but it should convey the point. Thanks Jamie On 3 June 2016 at 03:06, Shawn McKinney <[email protected]> wrote: > > > On Jun 2, 2016, at 10:58 AM, Adam Young <[email protected]> wrote: > > > > Any senseible RBAC setup would support this, but we are not using a > sensible one, we are using a hand rolled one. Replacing everything with > Fortress implies a complete rewrite of what we do now. Nuke it from orbit > type stuff. > > > > What I would rather focus on is the splitting of the current policy into > two parts: > > > > 1. Scope check done in code > > 2. Role check done in middleware > > > > Role check should be donebased on URL, not on the policy key like > identity:create_user > > > > > > Then, yes, a Fortress style query could be done, or it could be done by > asking the service itself. > > Mostly in agreement. I prefer to focus on the model (RBAC) rather than a > specific impl like Fortress. That is to say support the model and allow the > impl to remain pluggable. That way you enable many vendors to participate > in your ecosystem and more important, one isn’t tied to a specific backend > (ldapv3, sql, …) > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
