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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
