Difference between revisions of "QuantumAuthSpec"
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| − | + | == Introduction == | |
| − | + | This page discussed specification and implementation for authentication and authorization in the Quantum API. | |
== User roles == | == User roles == | ||
| + | |||
| + | Two roles: administrators and user | ||
| + | Administrator creates and 'owns' network (ie: can change its name). | ||
| + | Users can plug and unplug interfaces from the network (and likely also create/delete port). | ||
| + | Users can only operate on the port/interfaces they created. | ||
=== Analogies with real world scenarios === | === Analogies with real world scenarios === | ||
| + | |||
| + | Network switch in data centre - entirely managed by network administrators. Users, i.e.: machine owners, do not "create" port on switches. | ||
| + | Better analogy with wireless networks; administrators set up the network and provides access credential to users, which can then connect their devices to the wireless network. | ||
== AuthN/authZ model with single tenant == | == AuthN/authZ model with single tenant == | ||
| + | Administrator has complete control of the network, and can perform operations on each port and interface, including the ones created/plugged by other users. | ||
== AuthN/authZ model with multiple tenants == | == AuthN/authZ model with multiple tenants == | ||
| + | |||
| + | Administrator can give access to the network to other tenants; users from the other network will have the "user" role in network where they have been granted access, even if they are administrators in their own network. | ||
| + | |||
| + | Alternatively, it is possible to think about "Open" and "Private" networks. An open network is by default a public network to which each tenant can connect as a "user"; the network will be owned by the service provider, which could be modeled as a particular tenant. On the other hand, for private network, only the tenant which own the network can operate on it. | ||
| + | |||
| + | The Open/Private model suits particularly well a scenario in which a public network is available to tenants, which can however then create their own public networks; bridges (L2/L3) between private and public networks are at the moment outside the Quantum Scope, even if L2 bridging could become in the future part of the Quantum API. | ||
| + | |||
| + | On the other hand, the first model, in which a tenant can "extend" access to the network to other tenants suits well a scenario in which there might be several public networks; for instance a provider might allow tenants to join public networks with different levels of service. | ||
== Implementation == | == Implementation == | ||
Revision as of 14:46, 27 June 2011
Introduction
This page discussed specification and implementation for authentication and authorization in the Quantum API.
User roles
Two roles: administrators and user Administrator creates and 'owns' network (ie: can change its name). Users can plug and unplug interfaces from the network (and likely also create/delete port). Users can only operate on the port/interfaces they created.
Analogies with real world scenarios
Network switch in data centre - entirely managed by network administrators. Users, i.e.: machine owners, do not "create" port on switches. Better analogy with wireless networks; administrators set up the network and provides access credential to users, which can then connect their devices to the wireless network.
AuthN/authZ model with single tenant
Administrator has complete control of the network, and can perform operations on each port and interface, including the ones created/plugged by other users.
AuthN/authZ model with multiple tenants
Administrator can give access to the network to other tenants; users from the other network will have the "user" role in network where they have been granted access, even if they are administrators in their own network.
Alternatively, it is possible to think about "Open" and "Private" networks. An open network is by default a public network to which each tenant can connect as a "user"; the network will be owned by the service provider, which could be modeled as a particular tenant. On the other hand, for private network, only the tenant which own the network can operate on it.
The Open/Private model suits particularly well a scenario in which a public network is available to tenants, which can however then create their own public networks; bridges (L2/L3) between private and public networks are at the moment outside the Quantum Scope, even if L2 bridging could become in the future part of the Quantum API.
On the other hand, the first model, in which a tenant can "extend" access to the network to other tenants suits well a scenario in which there might be several public networks; for instance a provider might allow tenants to join public networks with different levels of service.
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.
