Difference between revisions of "QuantumAPIAuth"
m (Text replace - "__NOTOC__" to "") |
|||
| (2 intermediate revisions by one other user not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ||
Authentication + authorization of requests to the Quantum API is required so that tenants can only modify their own networks. | 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. | 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. | + | 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. | 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. | + | 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. | ||
Latest revision as of 23:30, 17 February 2013
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.
