openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

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 abuse@xxxxxxxxxxxxx, and delete the original message. 
> Your cooperation is appreciated.
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp