Enable Authorization support in Quantum

The goal of this blueprint is to provide basic authorization in Quantum by levearging keystone.

Note: the linked spec below is somewhat out-dated, but I believe still had the same general goals of introducing a simple authn/authz model based on keystone, so I will leave it to the new BP owner to modify or remove this link.

Etherpad notes from Folsom Summit:

  AuthN/AuthZ and RBAC for Quantum

  - goal is simple first model for Authn/Authz, just to expose Quantum API at all (currently, we can't expose Quantum to tenants without completing this item).
  - Need to do basic keystone integration for middleware on server, and on client library.
  - basic model is "tenant" or "admin". can grow over time.
  - Need to circle back with keystone team on this...
  - delegation of port ownership, very narrow rights. Example is letting tenant plug into a port on a public switch owned by the service provider.
  - can we do this integration in a way that it is not tighly-coupled with keystone? Might want to use quantum with other systesm. Maru says that swapping out wsgi middleware should be doable.
  - we should look at how Nova does this. They define capabilities in JSON file.
  - can we define capabilities for what we need in quantum? How would you represent ownership of a single port?
  - Keystone does not target per "instance" capabilities.
  - networks are a different type of resources. Networks can be shared resources, hence the need for delegation.
  - Key question: how do you give tenant control over a subset of the attributes on a network port? For example, service provider wants to prevent tenant from disabling anti-spoofing protections on a port, but does want to give the tenant control over security groups on that port.
  - Where is this implemented? Authn wsgi middleware seems pretty straightforward. Authz is trickier. Does plugin need to be able to do Authz, or this a generic component in the API layer.

Additional Questions:
- We will also need to update python-quantumclient and the CLI to be keystone aware. jkoelker seems to be reworking the client, so may be best to coordinate with him.