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

Reply via email to