Difference between revisions of "QuantumAuthSpec"
| Line 15: | Line 15: | ||
=== Integration with Keystone === | === Integration with Keystone === | ||
| + | |||
| + | Authentication + authorization of requests to the Quantum API is required so that tenants can only modify their own networks. | ||
| + | |||
| + | The plan is that authentication will follow the standard [[OpenStack]] model of using [[ https://launchpad.net/keystone | Keystone ]]. The "echo service" being created as part of Keystone as a template for this work ( https://github.com/khussein/keystone/tree/master/echo ). Work on this service continues, so we should check to see if it is ready for a pull. | ||
| + | |||
| + | For now, the plan is to start with a simple scheme were each network is only owned by a single tenant, and only that tenant can perform any of the operations on that network. | ||
| + | |||
| + | Also important is determining how we authenticate that a given user making a port attachment API call is authoritative for the associated interface-id. Obviously, one is only allowed to plug interfaces that they own. Seems like this call must understand the tenant that owns the interface-id and validate an authentication token confirming ownership of both the network switch and the interface. | ||
| + | |||
| + | During the summit, we discussed that the service-provider (or a service like nova) may itself act as a tenant to the quantum API in order to model networks. | ||
| + | |||
| + | Ideally, this code will be written in a way that is amenable to plugging in authentication stores other than Keystone. | ||
| + | |||
| + | Note: We should also consider how the notion of "Admin" APIs fit into this. Certain functionality, like the reporting of "interface bindings" from a remote service to Quantum will occur over this channel. | ||
=== Managing roles === | === Managing roles === | ||
=== Changes to Quantum API === | === Changes to Quantum API === | ||
Revision as of 14:03, 27 June 2011
Place Holder for Quantum API Authentication/Authorization specification
Introduction
User roles
Analogies with real world scenarios
AuthN/authZ model with single tenant
AuthN/authZ model with multiple tenants
Implementation
Integration with Keystone
Authentication + authorization of requests to the Quantum API is required so that tenants can only modify their own networks.
The plan is that authentication will follow the standard OpenStack model of using Keystone . The "echo service" being created as part of Keystone as a template for this work ( https://github.com/khussein/keystone/tree/master/echo ). Work on this service continues, so we should check to see if it is ready for a pull.
For now, the plan is to start with a simple scheme were each network is only owned by a single tenant, and only that tenant can perform any of the operations on that network.
Also important is determining how we authenticate that a given user making a port attachment API call is authoritative for the associated interface-id. Obviously, one is only allowed to plug interfaces that they own. Seems like this call must understand the tenant that owns the interface-id and validate an authentication token confirming ownership of both the network switch and the interface.
During the summit, we discussed that the service-provider (or a service like nova) may itself act as a tenant to the quantum API in order to model networks.
Ideally, this code will be written in a way that is amenable to plugging in authentication stores other than Keystone.
Note: We should also consider how the notion of "Admin" APIs fit into this. Certain functionality, like the reporting of "interface bindings" from a remote service to Quantum will occur over this channel.
