<br><br><div class="gmail_quote">On Thu, Aug 18, 2011 at 4:09 PM, John Dickinson <span dir="ltr"><<a href="mailto:me@not.mn">me@not.mn</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
On Aug 18, 2011, at 5:50 PM, Vishvananda Ishaya wrote:<br>
<br>
><br>
> On Aug 18, 2011, at 3:45 PM, Somik Behera wrote:<br>
><br>
>> Hi Vish,<br>
>><br>
>> That would be one very reasonable way to do it, but in that case we are fragmenting AuthZ in multiple services instead of Keystone taking care of AuthZ across all services.<br>
><br>
> We can't necessarily depend on keystone to keep track of all objects owned by each service.  Especially for things like swift where millions of objects are involved.  I therefore think the right solution is to have the services responsible for their own objects, and allow them to delegate to keystone in the cases where it makes sense.<br>

<br>
</div>(I hope I'm not getting into something here that I don't need to be in)<br>
<br>
The way this is handled in swift is a 2-phased approach. First, the auth system (keystone) can approve or deny a request up front if it already has enough in to do so. Second, the auth system provides an "authorize" method callback in the wsgi environment that swift can call at a later time in the request/response cycle. So after more information about the request is gathered (like ACLs stored on a particular object), swift calls the provided authorize method with the new info and then the final authorization determination is made.<br>

<br></blockquote><div><br>This approach sounds very similar to what Vish proposed, here instead of gathering "ACLs stored on a particular object", Quantum will check with Nova if the particular tenant has access to a specified VIF and then callback into Keystone for final authorization determination.<br>
<br>Based on both of your suggestions, I feel that asking Nova if a particular VIF is owned by a particular tenant and then invoking a Keystone callback for the final authorization decision seems to be the way to go at this point.<br>
<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Perhaps a similar approach could be used for other services.<br>
<br>
*Oh, and as a point of (boastful) clarification, swift will be storing billions of objects, not millions. ;-)<br>
<font color="#888888"><br>
--John<br>
</font><div class="im"><br>
><br>
>><br>
>> Depending on Keystone's roadmap and plans, we could take a 2 phased approach, where Nova doing AuthZ is a temporary solution till Keystone can do it or  if Keystone  is not going to have this capability, then we go down the path you are suggesting - Keystone does AuthN and we rely on Nova to authorize a tenant's access rights to a particular vif.<br>

>><br>
>> Thanks,<br>
>> Somik<br>
><br>
</div><div><div></div><div class="h5">> _______________________________________________<br>
> Mailing list: <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
> Post to     : <a href="mailto:openstack@lists.launchpad.net">openstack@lists.launchpad.net</a><br>
> Unsubscribe : <a href="https://launchpad.net/%7Eopenstack" target="_blank">https://launchpad.net/~openstack</a><br>
> More help   : <a href="https://help.launchpad.net/ListHelp" target="_blank">https://help.launchpad.net/ListHelp</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><font color="#666666">Somik Behera | Nicira Networks, Inc. | </font><a href="mailto:sbehera@nicira.com" target="_blank"><font color="#666666">somik@nicira.com</font></a><font color="#666666"> | office: 650-390-6790 | cell: 512-577-6645</font><br>