Open Stack

inline.

Thanks,
Somik

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

>
> On Aug 18, 2011, at 3:45 PM, Somik Behera wrote:
>
> > 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.
>
> 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.
>
>
I just wasn't sure if that's what we had decided, or Keystone was going to
be independently scalable system that can keep track of all object ids and
their AuthZ. If we have decided to delegate AuthZ to individual services,
that sounds like a perfectly reasonable way to to implement AuthZ. Along
those lines, are we then planning a generic Nova API that will take a token
and a resource( VM, vif or what have you) and say if the the token is
authorized to access the resource( or a action on a resource)




> >
> > 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
>



-- 
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/40ec09ec/attachment.html>