Jump to: navigation, search

FederatedAuthZwithZones

Revision as of 17:42, 4 April 2011 by SandyWalsh (talk)

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

User stories

Design

Implementation

Migration

Test/Demo Plan

Unresolved issues

BoF agenda and discussion