Salvatore, This sounds good to me; thanks for the writeup! I think the simplified model is a good first target for Diablo.
> 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. Agreed. > 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. We should be able to help next week as well...Arvind is expecting to land some Dashboard code mid-next-week (most operations other than attaching are already functional) and Tyler's work on packaging should be fairly quick. At Your Service, -- Mark T. Voelker Systems Development Unit (919) 392-4326 mvoel...@cisco.com On Wed, 2011-08-03 at 15:21 +0100, Salvatore Orlando 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 > > > >
signature.asc
Description: This is a digitally signed message part
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
