← Back to team overview

openstack team mailing list archive

Re: Federated Identity Management (bursting and zones)


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

Follow ups