Hi Salvatore, great summary of our discussions. I'm definitely in favor of focusing on this "basic" auth model for the Diablo timeframe.
Definitely agree that this will use Keystone, but as you mention, this basic use of keystone should be essentially plug-n-play. You and I will coordinate on communicating the data of interface ownership between nova + quantum, with respect to the quantum-manager work. I'm expecting that to start we can just report this data with the "interface bindings". Let's update the blueprint/spec with the text of your email below and target the blueprint to D-4. Dan On Wed, Aug 3, 2011 at 7:21 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote: > 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