openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

Eric:

I agree that your suggestion is simpler, but I think we are too limited if we remove multi-membership and per-object overrides.  Imagine that alice is an organization that has 10 users and a lot of instances.  If i create a group called alice_shares, then I have to remember to add all of other 10 users of alice to that group, and the instances are no longer logically grouped because they will show up at a different url or require a different set of credentials to access.  This sucks from a usability perspective.  I should also mention that if we are going to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet and jump into multiple ownership.

The original proposal was to keep a single owner, but allow resources to be overridden individually.  This gives me the freedom to give bob access to all of my instances, or some subset of them as i see fit.  It avoids the extra data and complication of managing service groups.  I think this is the simplest approach, but it does sacrifice the feature of managing permissions on sets of objects below the ownership level.

The resource groups that are suggested seem like something akin to tags, where you could tag a set of resources and give access to all of them.  In this scenario, the instances would still have alice as the owner, but some of them would be tagged "alice_shares".  These can actually be subject groups, but there has to be a mapping of resources to subjects somewhere, and i think that could actually be done in the service layer instead of the authz layer, perhaps even using instance metadata.  The drawback of this method is that it essentially boils down to multiple-ownership and requires auth api additiions to allow group creation and modification.

Resource groups does feels like it could be a bit YAGNI, but we definitely need some way for sharing to occur that maintains some usability.

On Apr 4, 2011, at 4:02 PM, Eric Day wrote:

> 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
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp