Hi, Quick update on the current status. Integration with keystone for authentication is quite easy and straightforward.
We are now able to authenticate Quantum requests with Keystone. I did not write a single line of code, but just used the keystone.middleware.auth_token.AuthProtocol class, which the same used for nova integration. A few things to iron out: * If no credentials are supplied, the middleware returns a 305-Use Proxy error, whereas I was kind of expecting a 401 error; * Details concerning Quantum endpoint still need to be provided in the configuration file, even if they're not used as quantum is in the same pipeline as the auth_token middleware; * Since validating a token is a "privileged" keystone operation, we need to provide an admin token in the configuration file. I'm not entirely sure this is the right approach, as should the token expire we would need to get a new token, update the configuration file, and then restart quantum. On authorization: If we agree to leave the auth_token middleware unchanged from keystone source code, we can develop a small authorization middleware for quantum. We can easily verify ownership of Quantum objects, and then synchronize with the nova-related work for verifying ownership for interfaces. On the other hand, if we decide to change the authentication middleware to address the above mentioned issues, we might as well do the authorization bits in the same piece of code. Important: The client library should be updated to add an X-Auth-Token to each request. Regards, Salvatore From: netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: 03 August 2011 23:34 To: Sumit Naiksatam (snaiksat); netstack@lists.launchpad.net Subject: Re: [Netstack] Tackling authN/authZ for Diablo-4 Hi Sumit, I used the terms "tenant" and "user" according to their definition for Keystone. Tenant: A container used to group or isolate resources and/or identity objects. Depending on the service operator, a tenant may map to a customer, account, organization, or project. User: Users have a login and may be assigned tokens to access resources. Users may be directly assigned to a particular tenant and behave as if they are contained in that tenant. "administrative rights" simply means to be allowed to perform all operation exposed by the Quantum API. We don't plan to have any form of network sharing for Diablo. This implies we will have a 1:n association between tenants and Quantum networks. Salvatore From: Sumit Naiksatam (snaiksat) [mailto:snaik...@cisco.com] Sent: 03 August 2011 17:21 To: Salvatore Orlando; netstack@lists.launchpad.net Subject: RE: [Netstack] Tackling authN/authZ for Diablo-4 Thanks Salv for spelling out the deliverables on this topic. On the point of the "simplified mode", I wasn't very clear on what you meant by "Although in theory several users can be defined for a tenant, we will assume that each user has the same administrative rights." Does this mean that each of those users (in their "administrator" capacity) would be able to share the network (i.e. more than one tenant plugging interfaces into the same network)? I was trying to reconcile that with the earlier statement on the "shared network model" which you mention is not in scope for Diablo. Thanks, ~Sumit. From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On Behalf Of Salvatore Orlando Sent: Wednesday, August 03, 2011 7:22 AM To: netstack@lists.launchpad.net Subject: [Netstack] Tackling authN/authZ for Diablo-4 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
