Hi Sandy, Thanks for putting this together, it really helps to facilitate the discussion. I do have a couple concerns though with this latest design.
The AuthZ services talk to each other. I don't see why this should be happening, since a zone can be configured to talk with a number of authz services directly depending on some prefix. For example, in the diagram on the wiki page, Service Provider zones could be configured to access authz.myco.com for any authentication requests that come in for the myco.com namespace. It doesn't need to touch authz.sp.com for any reason. You introduced resource groups, but I don't think we need resource groups, as those could simply be more fine-grained subject groups. In fact I think we should boil this down more to align with the previous auth discussions in that we're only dealing with 'accounts', and an account can be an owner, user, or group. For example, you could have the accounts: alice alice_shares bob When alice authenticates, you would get tuple describing alice can perform all actions for resources owned by alice and alice shares. Alice can also create resources under alice or alice_shares. When bob authenticates the tuples would allow bob to perform all actions for resources owned by bob, but also perhaps reboot resources owned by alice_shares. This model would give a great deal of flexibility and reduces the types involved to just a list of (account, actions) for each authenticated entity. Resources only need to track a single owner too, it doesn't need a list of resource groups it belong to or anything else. If believe this is much how swift already works as well. -Eric On Mon, Apr 04, 2011 at 08:19:36PM +0000, Sandy Walsh wrote: > Phew, ok, I've boiled down the various federated AuthZ discussions with eday, > vish & jorge. > > I've superseded the old blueprint since the bulk of the work is clearly in > the Federated AuthZ camp and not the AuthN camp. > > http://wiki.openstack.org/FederatedAuthZwithZones > > Shorter and more succinct. Should address many of the issues that have arisen > to date. > > -S > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of the > individual or entity to which this message is addressed, and unless otherwise > expressly indicated, is confidential and privileged information of Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at [email protected], and delete the original message. > Your cooperation is appreciated. > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
