Open Stack

Hi Vish,

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.

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.

Thanks,
Somik

On Thu, Aug 18, 2011 at 3:37 PM, Vishvananda Ishaya
<vishvananda at gmail.com>wrote:

>
> On Aug 18, 2011, at 2:08 PM, Somik Behera wrote:
>
>
>     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
> - *This is where we need AuthZ help from Keystone*
>
>
> 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.
>
>
>


-- 
Somik Behera | Nicira Networks, Inc. | somik at nicira.com <sbehera at nicira.com> |
office: 650-390-6790 | cell: 512-577-6645
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110818/d9a2f24c/attachment.html>