openstack team mailing list archive

[Eric Day <eday@xxxxxxxxxxxx>]

Hi everyone,

I thought I'd take a moment to summarize the state of auth
in the various OpenStack projects. With the recent discussion
of OpenStack API auth in nova (bug+revert), how to structure
accounts/users/projects/etc., and with Glance and Burrow needing
auth solutions, now seems like a good time to get our auth ducks in
a row. It is extremely important that we solidify our current auth
mechanisms and provide a simple way to share an auth system across
services so deployments don't need to manage auth for each service
independently. Before we can propose solutions, we need a common
understanding of where things are at now and where we would like to
go. Please correct me if any of the below information is incorrect.

Swift

Swift currently has two authentication solutions, "devauth" and
"swauth". The "devauth" solution is a wsgi middleware in Swift plus
stand alone server (in the Swift repo) that provides token based
auth. The stand alone server manages users, passwords, tokens, and
other information in a SQLite database and the Swift middleware uses
this to verify tokens and handle authorization requests. The devauth
solution may be going away in Diablo since it doesn't scale and swauth
is a better replacement.

The "swauth" wsgi middleware is all auth rolled up into one. It uses
the same token based auth scheme as devauth, but instead stores data
in Swift instead of SQLite. The reason for this is to provide a much
more scalable, self contained auth module for default swift installs.

Nova

There are currently two different API paths in Nova: EC2 and
OpenStack. The EC2 path uses the native EC2 method which consists
of a API key and signature. There is no intermediate token like the
Swift or Nova OpenStack API methods have. The OpenStack API works very
similar to the Swift middleware, except it uses the Nova pluggable
auth backends. It is a two-step process, first getting a token and
then using that token for subsequent requests.

Both the EC2 and OpenStack API auth modules are backed by the pluggable
auth mechanism in Nova. This currently supports three drivers: ldap,
fakeldap (in-process memory), and SQLAlchemy. The OpenStack API also
has a direct dependency on the SQLAlchemy driver for storing tokens
since the Nova auth interface doesn't manage tokens (it was designed
for ec2).

Glance

There is a branch by Jay Pipes that has the start for auth middleware,
see: https://blueprints.launchpad.net/glance/+spec/middleware-authentication

Other

There are also two other related blueprints:

https://blueprints.edge.launchpad.net/nova/+spec/nova-authn
https://blueprints.edge.launchpad.net/nova/+spec/bexar-auth-manager-api

The first is a proposal for defining a standard for pluggable auth
mechanisms and how this context should be passed around between
OpenStack services. The second is a proposal to expose auth management
functions inside of nova.

Tokens and Signatures

With the exception of the EC2 API module in Nova, all mechanisms
are token based auth. Token based auth requires a secure channel at
all times (both to generate the token and while using it) since the
token is as useful as the original login credentials until the token
expires. Signature based auth such as EC2 should also always require
a secure channel too, but if not attacks are less severe since they
are limited to reply attacks only (the request and parameters are used
as part of the signature). We can easily support both (and others),
but we need to understand the needs and constraints of each.

Next Steps

We need the ability for OpenStack projects to share a common
authentication source without each service needing to implement
auth management functionality. This may be backed by LDAP, Swift,
SQL database, etc. For deployments in new environments there needs to
be a reasonable default so users can add users in one place (probably
not through a specific service API) and all services can authenticate
against it. Also, no currently functionality should be removed.

I'll be writing a follow-up email with more details on entity structure
and a proposal to organize this, but at the very least there is a
need for common middleware mechanisms and an independent token auth
service. Each service should not need to manage it's own tokens like
Nova and Swift do today (although tokens will be stored in swift when
using it as a backend). Glance and other new services should be able
to easily reuse the mechanisms already provided.

-Eric