Difference between revisions of "FederatedAuthZwithZones"
| Line 28: | Line 28: | ||
[[Image:FederatedAuthZwithZones$UseCaseOverview.gif]] | [[Image:FederatedAuthZwithZones$UseCaseOverview.gif]] | ||
| − | == | + | == Terminology == |
| + | |||
| + | [[MyCo]].authZ = The AuthZ service running at [[MyCo]] | ||
| + | SP.authZ = The AuthZ service running at the Service Provider | ||
| + | Subject = The user performing the action. | ||
| + | Delegate = A user performing an action on behalf of another user. | ||
| + | Subject Group = A group of users or delegates. | ||
| + | Action = The verb being performed on the resource. Such as: boot, halt, pause, rescue, migrate, view, delete, etc. | ||
| + | Action Group = A collection of Actions. | ||
| + | Resource = The object the Subject is performing the Action on. | ||
| + | Resource Group = A group of Resources. | ||
== Design == | == Design == | ||
| + | |||
| + | After authenticating Alice with the Service Provider Zones, [[MyCo]].authZ will supply SP.authZ with a set if ''Permission Tuples'' that indicate which operations Alice may perform and which Resources she may perform them on (where applicable). These tuples have the mapping (Action_Group, Resource_Group). Note that Subject is implied here since the User had to previously authenticate with the system to gain access. | ||
| + | |||
| + | == User stories == | ||
== Implementation == | == Implementation == | ||
Revision as of 17:50, 4 April 2011
- Launchpad Entry: NovaSpec:nova-zones-federated-authz
- Created: SandyWalsh
- Contributors:
- Related: ZonesOauth http://etherpad.openstack.org/nova-oauth
Summary
In the current Zones implementation, all operations to child zones are done with an admin account. While this works, it causes problems in certain important use cases. Specifically when a user wishes to see all the instances that he may manage. With the admin-account approach, all instances in child zones are returned when only a subset should be (depending in the users rights).
This page is the culmination of discussions with eday, vish, jorge, khaled and others and attempts to summarize the problems that may arise in other use cases as well as documenting the proposals currently underway for solving them.
Release Note
Rationale
Assumptions
This will be the common scenario for the bulk of these use cases.
MyCo is a small software development shop. They have a Nova deployment made up of two Zones (parent and child). When these two zones are incapable of providing more instances, MyCo outsources to Service Provider (SP) to handle the extra work. SP is large and has many Zones geographically separated and nested many levels deep.
There are two main users in our use cases: Alice and Bob. Alice manages her own instances, as does Bob. However, Alice and Bob are also members of a Financial Task Force which gives them the ability to manage any instances under that groups control.
There will be one set of AuthN and AuthZ services per business. MyCo has it's own AuthN/Z service as does SP.
Whenever a user is added/removed from a security group or permissions changed they are done on the MyCo side. These changes need to be propagated to the SP side as needed.
File:FederatedAuthZwithZones$UseCaseOverview.gif
Terminology
MyCo.authZ = The AuthZ service running at MyCo SP.authZ = The AuthZ service running at the Service Provider Subject = The user performing the action. Delegate = A user performing an action on behalf of another user. Subject Group = A group of users or delegates. Action = The verb being performed on the resource. Such as: boot, halt, pause, rescue, migrate, view, delete, etc. Action Group = A collection of Actions. Resource = The object the Subject is performing the Action on. Resource Group = A group of Resources.
Design
After authenticating Alice with the Service Provider Zones, MyCo.authZ will supply SP.authZ with a set if Permission Tuples that indicate which operations Alice may perform and which Resources she may perform them on (where applicable). These tuples have the mapping (Action_Group, Resource_Group). Note that Subject is implied here since the User had to previously authenticate with the system to gain access.
