Best Regard Hugo K.
Vishvananda Ishaya <[email protected]> 於 2011/3/31 6:29 寫道： > 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. >> > > > _______________________________________________ > 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
