Auth proposal

This document is a blueprint for the to-be-implemented authentication and authorization support in HaaS. Pull request #491 is tracking the implementation effort.

Conceptual Model

Authorization

• Two kinds of authorization exist:
  • Admin authorization, which allows access to admin-only API calls (e.g. switch_register...)
  • Project authorization, which allows managing the resources of a particular project.

The details of exactly which operations require what authorization will be described in docs/rest_api.md in the HaaS source tree.

Authentication

Authentication is entirely backend-dependent. Individual extensions define what requirements the request must meet in order to perform authentication.

Implementation

Each authentication backend is a standard HaaS python extension, and must implement the interface described in (the newly written) haas.auth.

The main request handler will invoke the extensions authenticate() method before dispatching to the particular API call. The API call can use require_admin() and require_project_access() as needed to implement specific policy.

• henn Does this mean that every API call will need to be parsed by the auth backend, then re-parsed by the API call itself?

Initial backends

Initially, there will be two backends:

• A null backend, which simply authorizes everything (and requires no specific authentication).
• A backend based on usernames and passwords stored in the DB.
  • Use HTTP Basic Auth for the autheticate() step.
  • Users can be members of projects, which determines project access
  • The users table has a column is_admin, which is checked for admin access.

A Keystone backend will likely be soon to follow.

API namespace

The username/password/database backend uses custom api calls (for creating users, adding/removing them to/from projects, etc). Since this is the first time we've had an API call defined from an extension, we need to pause and consider the implications. The main thing I see is that we should have some way of namespacing API calls defined in extensions. Proposal:

• All API calls defined by extensions go somewhere under /ext

• Auth related API calls go under /ext/auth.

• henn It might make sense to group the API calls by functionality area, since presumably a lot of functionality could be provided by extensions in the future (like keystone auth, various switch-specific things) and it'd be messier to expose all of that to the user. In this case, that could look like /auth/basic or in the future /auth/keystone.

Bootstrapping

With the username/password backend, there must be a way to populate the database with an initial admin user. Proposal: write a script which prompts for a username and password, and adds the initial user to the database.