Open Stack

Hi everyone,

I'd like to build off the last auth thread about where the various
auth components are today and now look at what types of entities they
manage. Right now only Swift and Nova have entities, so only those
will be mentioned.

Swift

Swift has the concept of accounts, users, and groups. An account
contains users, and a user can belong to groups. Accounts names have an
abstraction layer, so while you may login with account "example.com",
the account name used within swift is a UUID with a prefix.

By default, a user belongs to a group for the user "user:account"
and a group for the account "account". The other group names can
be arbitrary strings, so they may be other account names, users,
or some application-specific term.

All operations are done in the context of a user and account. A user
may not be a member of the account it's acting on since resources
can specify ACLs, this is especially true for public resources (where
user is undefined or anonymous).

Nova

Nova currently has users and groups. Users can belong to more than
one project, and all operations must happen in the context of a
user and project. A user has flags such as admin, supervisor, and
project manager, along with the ability to have other service-specific
roles. A project simply has members (users), and those members can
have roles for the project. Roles are just strings such as "sysadmin"
or "netadmin" that other components can use for control. Roles may
be assigned per-project or at a global level.

Entities

To provide a common auth system for Swift, Nova, and new services,
we need to support the entities and functionality provided by both
existing services, along with any other needs we may have that are
not addressed yet. If we take the following steps, I think we can
model both systems into one:

* Create a new abstract "entity" type that contains a name, aliases
  (for service friendly names like swift uses), password/secret, and a
  list of other entities it belongs to. An entry in this entity list
  doesn't need to be represented as an object in the auth system,
  it can simply be a string or some other token (like some group
  entries in swift or roles in nova).

* Swift accounts become entities.

* Swift users become entities, renaming swift user "groups" as the
  list of entities the user entity belongs to.

* Nova projects become entities, with the entity list becoming the
  current list of members.

* Nova users become entities, turning admin/supervisor/manager flags
  into strings in the entity list, along with roles being moved into
  the entity list.

With this simple abstraction, I think we can map both projects onto one
system. Swift uses an "account:user" string to login with, but instead
this would instead be "entity" where the entity name=account:user. For
nova, an EC2 login consists of "access_key:project" where an access_key
maps to a user. This can stay the same, except access_key may be
an alias for an entity representing a user, and project would be an
entity with name=project.

For the OpenStack API, we need something a bit different from what we
have today. We currently have no way of passing in a project name,
so I propose we add an "entity" element to the path name (just like
Swift does). For example, instead of "/v1.0/servers/1", it would be
"/v1.0/entity/servers/1", where entity can represent an account (like
swift), project (like current nova), or even a user entity (deployments
where projects or accounts are not used). Our window for OpenStack
API changes is still open as it's still under heavy development,
and I think this path addition will provide more functionality and
a consistent structure across services (glance and burrow will be
using an account or "entity" in the path as well).

I've not thought this through with great detail and am not as familiar
with the swift side, so please point out any shortcomings you may
see. I think it's important to resolve these naming and behavioral
differences for a common auth system so new projects that want to
interact or share users/accounts/projects/entities with both services
only need to map to one scheme.

-Eric