On Thu, Aug 18, 2011 at 4:09 PM, John Dickinson <[email protected]> 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 : [email protected] > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > -- Somik Behera | Nicira Networks, Inc. | [email protected] <[email protected]> | office: 650-390-6790 | cell: 512-577-6645
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
