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>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 class="gmail_quote">On Thu, Aug 18, 2011 at 3:37 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com">vishvananda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><br><div><div>On Aug 18, 2011, at 2:08 PM, Somik Behera wrote:</div><br><blockquote type="cite"><br>
    2.2) Quantum needs to ensure Tenant-X( or user with access to Tenant-X) owns Virtual Network Interface named "instance-0001-eth0" available in Nova - <b>This is where we need AuthZ help from Keystone</b><br>
</blockquote><br></div></div><div>It seems simpler to me to have a quantum call nova with something like get_virtual_interface and pass the token.  Then nova can decide if that token has access to the vif.</div><div><br></div>
<div><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>