> From: Vishvananda Ishaya [[email protected]]
>
> 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 [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
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
