On Apr 4, 2011, at 6:46 PM, Eric Day wrote: > 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.
Ah i thought the suggestion had been changed to returning only one "account" per id. I see that is not the case now. We still have issues with listing instances accross accounts or groups which i mentioned in my other email. > >> 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? I think account/action tuple isn't too complicated. If we decide not to use use the resource_groups as tags, meaning multiple can be applied to same object, then we probably need this functionality. Or else we will have some crazy user with a different resource_group owner for every single vm in their organization. > >> 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). Yes, I was agreeing with your point. Again the multilple ownership I was suggesting was single-ownership with tags that act as pseudo-owners. Canonical url can still be under the "owner", but allowing to list by tag, for example, makes listing all the instances under a shared group possible without crazy aggregation schemes. Again, not sure it is worth the complexity, so if we can find a way around the listing issues and organization level roles issues that I mentioned in my other email, I'm happy to avoid it. > > -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 [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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
