Launchpad Entry: nova-oauth
Contributors: SandyWalsh
NOTE: While this spec started off with a focus on OAuth between Zones, it quickly turned into a discussion of federated AuthZ (which is where the real design problem is). This page is left around for history sake. The new discussion has moved to FederatedAuthZwithZones.
Summary
This blueprint is an investigation into how OAuth might be used as a federated identity mechanism in Nova. Particularly of interest is the sharing of user information between zones without having to replicate the user record & credentials between zones.
This is a work in progress and I'm not even sure it will work yet. If anything it will help us flesh out the Use Cases for design requirements. Note: Heavily revised and edited after this conversation http://paste.openstack.org/show/1075/
Mental Note (Sandy)
There might be a way to greatly simplify this if we assume that Zone A can talk to Zone B through a set of admin account. One per management group. This keeps everything very simple. Need to expand on this.
Assumptions
The main scenario in this discussion is private Zone A (from MyCo company) using Service Provider (SP) in Zone B.
- There is one HA AuthN and AuthZ service per business installation.
- These services may co-exist.
- These services are outside of the Zones (i.e. it's not one auth service per zone)
Alice and Bob are MyCo users. They manage their own instances, but they also belong to a Task Force where the instances may be managed by either.
Booting an Instance in a Child Zone (Happy Day)
Let's assume user Alice wants to boot a new instance. She issues a 'nova boot myzerver --flavor 1 --server 1' command against the Parent Zone (her private development Zone), but the local Compute nodes are all full. The Scheduler service routes the call to one of her child Zones. In this case a Zone owned by an OpenStack Service Provider.
The SP does not know about user Alice, so it needs to use OAuth to authenticate the user against the Parent Zone OAuth service (which does know about Alice).
Once authenticated, all of the authorization steps need to occur. Can Alice boot a new instance and incur credit card expenses on behalf of MyCo?
The above diagram illustrates a typical AuthZ structure within a single business. There are Subjects (the people trying to do stuff), Actions (the Verbs; the things the Subjects are trying to do) and the Objects (the things the Subjects are trying to perform Actions on. The individual Actions can be considered rights the Subjects have over the Objects. Rights are the things that need to be common between Nova installations. A particular installation might have additional Rights for their location, but a common/base set would be required for hybrid clusters.
But it gets a little more complicated in the federated scenario because Objects and Subjects are not shared between installations. The SP only knows the project (MyCo) that Alice and Bob belong to and the Instances that were created by them.
Alice may have already created instance ami-AAAA and Bob ami-BBBB.
Operations like Boot are pretty easy because they have no Subject. It's a general permission of "Can Alice Boot a new Instance?"
After being AuthN'ed, Zone A will supply a set of permission tuples to the SP that says what Alice can do. In this case, she can boot new instances. So, instance ami-AAA2 is created and the instance ID returned to Zone A for subsequent actions.
Later, we want to give Bob access to ami-AAA2. We would have to do this through the MyCo AuthZ system.
When Bob logs in (successfully authenticates), Zone A supplies Zone B with the set of Bob's permission tuples.
Zone B knows nothing of the Task Force Group, so Zone A has to supply these permission tuples in a form that Zone B can understand. This might take the following form: (can_halt, Alice) ... which gives Bob permission to halt instances owned by Alice.
Note: Why grant (can_halt, Alice) vs. (can_halt, ami-AAA2)? There could be millions of objects under control and flattening the list could get very expensive. (Sandy: however, I think this current scheme of (action, user) is too open. Bob should not be able to halt Alice's ami-AAAA instance.
AuthN Questions:
- During the Resource Owner Authorization step, the Parent OAuth Service needs to ask Nova Client for Alice's credentials (which it has). There are a bunch of issues here:
- - Nova Client has already authenticated against the Parent Zone, perhaps all that is required is for the Child Zone to be passed this already-authenticated OAuth token?
- Since the OAuth Consumer Key is different for Novaclient and the Child Zone, this may not work (or be safe). Perhaps the Child Zone should reauthenticate. If so, Parent Zone will need to ask NovaClient to re-assert the credentials. But how? NovaClient is a command-line tool and has no web interface for redirection.
- - Nova Client has already authenticated against the Parent Zone, perhaps all that is required is for the Child Zone to be passed this already-authenticated OAuth token?
------------------------- EDITING NOT COMPLETED BELOW HERE ---------------------
The End User Experience (AuthN)
I have some concerns about the user experience with OAuth. Let's assume Alice tries to boot a new instance and the request is handed off to Service Provider for provisioning. The SP will call back to Zone A to get permission to boot the instance. At this point the user will be asked to confirm the request (assuming this is the first interaction the user has had with this Zone). So, here's an authenticated user getting this seemingly random prompt
"ServiceProvider.DataCenter.Tower2 would like access to your Permissions. Will you grant this?"
Huh? That would make no sense. Even less given the fact that the user had to authenticate to get to Zone A in the first place (her credentials have already been given to the client tool).
Showing All Instances Owned by User
tbd
Thoughts on Federated AuthZ
After further discussion on the ML, the issue of federated AuthZ came up. On the ML this was described as shared Groups, but I think the reality is only slightly different. Given the standard RBAC model of Rights & Roles, an agreed-upon set of Rights (aka strings) might be better for sharing permissions between Nova deployments. Of course, if you want to think of Collections of Actions as "Action Groups", that works.
In the federated scenario, the private AuthN system needs to supply Tuples of (Action, Objects) that the Subject can perform. Let's assume the AuthN system has already mapped the Private User definition with the Service Providers User definition (ie. authenticating Alice between both installations).
Given that, the only thing left is for Zone A to supply the identifiers for the Objects that Alice can perform Actions on.
This actually isn't so bad. Whenever a new Object is created or destroyed in Nova, the AuthZ would have to be notified of it. All Objects within Nova that are to be controlled by AuthZ would have to be ripped out of Nova and placed under the control of AuthZ. This means that Nova itself would not do any AuthZ computations, just enforcement. Instead, it would simply go back to the AuthZ system and say "Given this User (token) and Object (id) can I perform (this) Action?" Whenever a new Instance, Project or User is added or deleted a notification would have to be sent to the AuthZ system for it to update its records.
This is illustrated below:
In the use case of Alice booting a new Instance in Zone B, the Zone B AuthZ system would get updated that there is a new ami-38982634 instance created and the ID of this instance returned to Zone A. Zone A Nova would relay this information to its AuthZ, which would remember this instance as a new Object it has rights over, but it would mark it as an externally managed Object. Externally Managed Objects are Objects that don't live in this deployment, but are included for AuthZ purposes. Whenever Alice authenticates to Zone B her permissions are supplied using the parlance of Zone B, but formulated in Zone A.
Note:: Projects may need to get mapped in a similar fashion. This needs a little more thought. Zone A should own the Project definitions and denormalize/flatten the instance ID's when handing it off to Zone B. Zone B would only know that Bob and Alice are part of the MyCo project ... not the particulars of the inner projects within MyCo.
We would also need a means to "freshen" an authorized Subject token once it's in system. I think this is outside the scope of OAuth.
Notes from Vish
1. We were discussing removing the concept of project completely from nova, since it is an AuthN concern. Instead, we have an "owner" for each object. The owner could be a "project" in our original sense, but it could also be a user, and organization, etc.
Sandy: Agreed. I think all Nova should just focus on Instances, Volumes and Networks. All multi-tenant, project & billing issues should be moved to the Auth mechanism.
2. The way that we are handling objects in authz inside of the prototype authz branch is by having a default set of rules in authz that can apply to most objects. The authz then exposes a simple call that allows users to override permissions for a particular owner or a particular owner/object. This seems to give us a pretty decent level of control without forcing us to replicate every single object into authz.
- Sandy: The override mechanism seems clunky to me. How do we sync this between Zone A and Zone B and between all child zones from Zone B? Seems like poor-man's replication.
3. My initial thought that the process of overriding permissions needs to go through the services themselves, as opposed to directly through authz. This allows a service to have different authz services per compute service or even use some kind of internal authz. In swift for example, it likely makes sense for the permissions to be stored with with the object in a distributed fashion (as they currently do). In this model, the call to change permissions for an instance would be a call to nova with something like update_permission(subject="foo.alice", action="terminate", id="bar.instance.xxx"). Because the services are federated, ZoneA would pass the call to ZoneB, and ZoneB would make the override in its own authz system. This would require that we come up with a canonical zone-aware naming system for ids, but i think we have to deal with that anyway.
- Sandy: My assumption was that Nova services were meant to be light-weight works that serviced queue requests, but putting the weight of authZ processing in each service would impact the size of each Nova Zone. However, if we assume that each AuthZ check requires an RPC call to the AuthZ service, that too will impact performance.
4. Speaking of which has any thought been given to federated zones for swift?
- Sandy: Don't know anything about Swift AuthN/Z yet.
Q: When Zone A adds Fred to "Task Force" project ... how do we inform Zone B of the permission change? A: He has to log in again.
Adding a Child Zone
As part of the Zone design, Child Zones know nothing of Parent Zones. When we add a Child Zone to a Zone we will need to tell the Child Zone to register itself as a Client Application of the Parent Zone. Normally, this is done via a web page (such as the Twitter Client Registration Form: https://dev.twitter.com/apps/new ... but we may want to automate this (?).
One the Child Zone has been added and it has registered itself as a Client Application of the Parent Zone, it may use OAuth federated identities for provisioning.
Assumptions:
- The Parent Zone has a publicly available registration service.
Questions:
- How does the Child Zone know which Parent Zone the user came from?
If we have multiple OAuth services (one per Zone), we would have to delegate this command to each child zone as well:
