Open Stack

On Thu, Aug 18, 2011 at 4:09 PM, John Dickinson <me at not.mn> wrote:

>
> On Aug 18, 2011, at 5:50 PM, Vishvananda Ishaya 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 hope I'm not getting into something here that I don't need to be in)
>
> 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.
>
>
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.

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.



> Perhaps a similar approach could be used for other services.
>
> *Oh, and as a point of (boastful) clarification, swift will be storing
> billions of objects, not millions. ;-)
>
> --John
>
> >
> >>
> >> 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
> >
> > _______________________________________________
> > Mailing list: https://launchpad.net/~openstack
> > Post to     : openstack at lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~openstack
> > More help   : https://help.launchpad.net/ListHelp
>
>


-- 
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/2f5a30ef/attachment.html>