[openstack-dev] [keystone][security] Service User Permissions
jamielennox at gmail.com
Thu Jun 16 06:19:07 UTC 2016
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):
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.
On 3 June 2016 at 03:06, Shawn McKinney <smckinney at symas.com> wrote:
> > On Jun 2, 2016, at 10:58 AM, Adam Young <ayoung at redhat.com> 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
> > 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev