On Tue, Aug 9, 2011 at 9:29 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote:
> Hi, **** > > ** ** > > Quick update on the current status. **** > > Integration with keystone for authentication is quite easy and > straightforward. > wish everything was that simple :) do you have a pointer to instructions on how to setup users and projects? I also assume we'll want an easy way to disable the auth for simple dev setups. > **** > > ** ** > > 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. > huh... that seems odd. Is this something we should bring up with the keystone team? > **** > > ** ** > > 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. > Yes. Are we tracking this as part of the main blueprint, or do we need to add a separate blueprint? Dan > **** > > ** ** > > 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 > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks, Inc. www.nicira.com | www.openvswitch.org Sr. Product Manager cell: 650-906-2650 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp