Made a few notes on thoughts at the bottom. I won't replicate the notes here because it kind of requires reading through the link you supplied first. In short, I think we have some options for keeping AuthZ isolated to a given deployment and even a given service. I like this approach, because I want to minimize the number of contact points between different deployments.
Vish On Apr 1, 2011, at 7:40 AM, Sandy Walsh wrote: > I was stewing on the suggestion of subject/verb/object tuples. There's a > gotcha in the federated AuthZ situation: mapping Public and Private Objects > in the tuples. Essentially, who owns the rights over the object if the object > is externally managed (by, let's say, a service provider). > > My thoughts around how Federated AuthZ might work in Nova are updated here: > http://wiki.openstack.org/ZonesOauth#Thoughts_on_Federated_AuthZ > > (and made some slight tweaks to map it to conventional RBAC schemes) > > Please burn/spindle/mutilate ... > -S > > ________________________________________ > From: Vishvananda Ishaya [[email protected]] > Sent: Wednesday, March 30, 2011 7:29 PM > To: Sandy Walsh > Cc: Jay Pipes; [email protected] > Subject: Re: [Openstack] Federated Identity Management (bursting and zones) > > I think authz is simplest if we just give it the responsibility of mapping > subjects, verbs, and objects. > > subjects are returned by authn. They can be users/projects/roles/groups/etc, > but are basically opaque > verbs are defined by the application: > launch_instance, get_volume, get_container, etc. > objects are the entities that actions are performed on. > > Then the authz system can just define how these three are mapped to create a > pass/fail. > > There can be some magic in the rules to make this much easier: > > 1) the concept of an object_owner. This allows rules to match the stuff > returned by authn to an "owner" field on the object > > 2) dividing groups of actions into certain "roles" or "groups" returned by > authn. The obvious one here is "admin", but other general roles could be > defined as well. I'm not sure how we validate the roles returned by an > external authn server. We don't really want Alice's admins to have full > admin rights to our deploy. Perhaps some namespacing here is necessary. > alice.admin vs mydeploy.admin > > Vish > > On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote: > >> From: Jay Pipes [[email protected]] >> >>> Come to think of it, there's no reason that role A would need to have >>> similar privileges in >> zones X and Y. More likely than not, they would have different >> privileges, and therefore a federated authz service wouldn't really >> make sense. >> >> I see your point, I was thinking at the Rights level, not Roles/Groups, and >> envisioning Rights like: >> >> can_boot_os=windows;linux >> can_boot_flavor=tiny;small;medium >> can_migrate_outside_zone=True >> maximum_ram_size=512m >> >> Certainly, we could have pre-established Rights just as we would have common >> Roles/groups. >> >> -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. >> > > > > 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
