Open Stack

Hi Vish,

On Mon, Apr 04, 2011 at 05:56:38PM -0700, Vishvananda Ishaya wrote:
> 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.

Sorry for the confusion, I was only addressing the extra layer of
resource groups that was proposed on the wiki page. I didn't mention
per-object permissions, but I agree we still need them. I realize now
my example is a misleading one (and can be better solved by per-object
permissions), but it was only there to show another way it could be
done without "resource groups" as they were proposed.

When you say we can't "remove multi-membership", what exactly do you
mean? I agree, and was not proposing that since an authentication ID
can list as many account/action tuples as needed.

> 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.

I think we can still do this with single owner plus per-resource
overrides, the override list would be one of the account ID's returned
for an authenticated user, which could be returned for multiple users.

There is the question of whether the per-resource override should
simply be an account ID or another account/action tuple, and I'm
not 100% sure. I think we could allow tuples for more fine-grained
control, but would be a bit more logic to match actions and not just
account IDs. If we keep tuples here and in the list returned from
authentication, is this excessive or too complicated?

> 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.

"These can actually be subject groups, ..." was what I was trying to
say with my example. :)  Wouldn't the mapping of resources to subject
groups be the per-resource overrides in the service layer? I'm not
sure why multiple ownership is needed. I think we need to avoid
multiple ownership, since this makes many other components ambiguous
(such as a canonical URL, who to bill, etc).

-Eric

> 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 at rackspace.com, and delete the original message. 
> >> Your cooperation is appreciated.
> >> 
> >> 
> >> _______________________________________________
> >> 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
> > 
> > _______________________________________________
> > 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