<div dir="ltr"><div><div><div><div><div><div><div>Thanks everyone for your input. <br><br></div>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. <br><br></div>To this end i've proposed reservations (a name that doesn't feel right): <a href="https://review.openstack.org/#/c/330329/">https://review.openstack.org/#/c/330329/</a><br><br></div>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. <br><br></div>Please let me know of any concerns/thoughts on the new approach.<br><br></div>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. <br><br><br></div>Thanks <br><br></div>Jamie<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 June 2016 at 03:06, Shawn McKinney <span dir="ltr"><<a href="mailto:smckinney@symas.com" target="_blank">smckinney@symas.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jun 2, 2016, at 10:58 AM, Adam Young <<a href="mailto:ayoung@redhat.com">ayoung@redhat.com</a>> wrote:<br>
><br>
> 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.<br>
><br>
> What I would rather focus on is the splitting of the current policy into two parts:<br>
><br>
> 1. Scope check done in code<br>
> 2. Role check done in middleware<br>
><br>
> Role check should be donebased on URL, not on the policy key like identity:create_user<br>
><br>
><br>
> Then, yes, a Fortress style query could be done, or it could be done by asking the service itself.<br>
<br>
</span>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, …)<br>
<div class="HOEnZb"><div class="h5">__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>