Jump to: navigation, search

Difference between revisions of "FederatedAuthZwithZones"

Line 22: Line 22:
 
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 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.  
+
There will be one set of AuthN and AuthZ services per business. [[MyCo]] has it's own AuthN/Z service as does SP. These Auth services will need to be Highly Available.
  
 
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.
 
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.
 +
 +
After authenticating, not only will the Auth Server have to supply the API URL to the caller, but it will need to supply the AuthZ URL to the caller for synchronization operations.
 +
 +
For child zones within the same business (ie. all the child zones in Service Provider) group ID's and resource ID's will have to be unique across Zones.
  
 
[[Image:FederatedAuthZwithZones$UseCaseOverview.gif]]
 
[[Image:FederatedAuthZwithZones$UseCaseOverview.gif]]

Revision as of 20:01, 4 April 2011

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. These Auth services will need to be Highly Available.

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.

After authenticating, not only will the Auth Server have to supply the API URL to the caller, but it will need to supply the AuthZ URL to the caller for synchronization operations.

For child zones within the same business (ie. all the child zones in Service Provider) group ID's and resource ID's will have to be unique across Zones.

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.

Side note: There was a discussion of having the tuple be (Action_Group, User_Group) where User_Group was a collection of Users that owned resources. The downside with this approach is it's not fine-grained enough. For example, if Bob has permissions (can_halt, [Alice]) then he can halt all instances owned by Alice. That's too much privilege.

We don't want the tuples to be so fine grained that we are listing individual instance ID's ... it won't scale to thousands of instances. While it would be easier, we don't want permission tuples of (Action_Group, [Resources ID's]) like (can_halt, [ami-AAA, ami-BBB, ami-CCC, ...]). Instead we need to define a Group of resources at the SP.authZ layer and simply refer to it in our permission tuples.

How? In order to do this, MyCo.authZ needs to keep SP.authZ updated with a discrete set of Resource Groups.

MyCo.authZ will have many Resource Groups and much of the contents of these Resource Groups will contain resources that live in MyCo Zones. We don't need to replicate all of this information to SP.authZ ... only a subset of the group that references resources that live in SP Zones. For example, the Finance Group as defined in MyCo.authZ may look like:


(Bob, [can_halt, can_see, can_boot, ...], [myco-AAA, myco-BBB, myco-CCC, sp-AAA, sp-BBB, sp-CCC])


but when passing this on to SP.authZ only the following is required:


([can_halt, can_see, can_boot, ...], [sp-AAA, sp-BBB, sp-CCC])


File:FederatedAuthZwithZones$SyncAuthZ.gif

User stories

Implementation

Migration

Test/Demo Plan

Unresolved issues

BoF agenda and discussion