openstack team mailing list archive

[Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>]

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

Correct, sorry again for the confusion.

> groups = AuthZ.get_resource_groups('alice')
> instances = set()
> for group in groups:
>     instances.union(set(nova.get_instances(group)))
> return instances

Agree that this could result in lots of little queries as written above, but the db can do all the work quite easily with some small tweaks.

return nova.get_instances(groups)

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

Either that or a wildcard for all perhaps?

(Jon, can_isolate, *)

Returning a large list of resource groups shouldn't be unmanageable. In reality it's still probably 1-2 orders or magnitude smaller than the resource ID's. It's certainly in the realm of most LDAP servers. 

-S

> 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



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.