openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

Ok, as I read it now, the resource groups are really a different terminology for the same thing we were discussing before.  The difference is that in this model the resource group always ends up as the "owner" of the project.

I would still suggest that this makes some actions inside a service very annoying.  How does one list all of the instances belonging to an organization, or accessible to a user?  Do we push to the client side?

groups = AuthZ.get_resource_groups('alice')

instances = set()
for group in groups:
    instances.union(set(nova.get_instances(group)))
return instances

I'm also not sure that it gives us useful control over something like roles.  Imagine Jon, a security adminstrator for OrganizationA. You want him to be able to network isolate vms for OrganizationA.   How do you specify that he can isolate any one of OrganizationAs instances?

(Jon, can_isolate, ????)

Is it assumed that we specify a special role and Auth is going to return a giant list of all of the resource groups that are in organizationA?

Vish

On Apr 5, 2011, at 4:39 AM, Sandy Walsh wrote:

> Doh! I'm an idiot. Write that down.
> 
> Eric, you're correct, we don't need to sync the AuthZ servers. We only need to pass the Resource Group ID's along after the user authenticates (thanks Jorge for reminding me.)
> 
> This is along the lines of what you have been suggesting with different User accounts, but without overloading Accounts and sticking to the "Collection of Resources" idea (as used in RBAC, SAML, etc)
> 
> There is a complexity here. When we create new Resources on the SP side we need to know which Resource Group to create it on behalf of. 
> 
> I've put a little description of the problem here: http://wiki.openstack.org/FederatedAuthZwithZones#On_Behalf_Of
> 
> The rest of the wiki has been updated to reflect these changes.
> 
> -S
> 
> PS> I think we're close to putting a pin in this thing.
> 
> 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