Hi, During yesterday's meeting we agreed that we needed to have some form of authentication and authorization in Quantum for Diablo. We also agreed we will be doing Keystone integration (please correct me if I'm wrong).
I think we can safely say what we will NOT deliver for Diablo: * Full RBAC model including the ability of specifying different roles for tenants' user (e.g.: "Alice" is an administrator and can do anything for tenant "A", whereas "Bob" is a simple user and can only plug its own interface into networks owned by tenant "A") * Shared network model, in which a tenant owns the network, but other tenants can plug interfaces into it. This use case will be useful for "public" and possibly "service" networks. What we will deliver can be summarized as follows: * Simplified model: only one "administrator" user per tenant. Although in theory several users can be defined for a tenant, we will assume that each user has the same administrative rights. * Authentication service: users must authenticate before submitting requests to Quantum API o The plan is to integrate Quantum with Keystone. The user will authenticate with Keystone, which will return an authentication token, which should be used for subsequent requests to Quantum API. Quantum API will validate this token with Keystone; I actually think we could achieve this without adding a single line of code to Quantum. * Object ownership verification: Before dispatching a call to a plugin the Quantum service layer must verify that all the resources involved are owned by the tenant submitting the request. o This can be handled with an authZ middleware which will precede the API app in the wsgi pipeline. Even if it could be handled within the API layer, I reckon it will be better to keep it orthogonal. o Interfaces being plugged in a port are the tricky bit: they are not owned by Quantum. We will need to query nova in order to know whether a tenant owns or not an interface. If I'm not wrong Dan will look after this (quantum-manager blueprint in nova) o We would be happy to avoid storing information about object ownership in the service layer and keep the database into the plugin. For networks and ports, the existing plugin interface is probably already good enough to return the appropriate ownership information. I am freeing some work cycles to start tackling these issues. I should be able to set aside 2-3 working days in the next two weeks. Mark, Dan, and other interested: please give me your feedback! Salvatore
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
