Support Groups of Users within Keystone

Registered by Henry Nash on 2012-11-12

With the v3 API, the Domain concept is designed to encapsulate users and projects representing some kind of logical entity (e.g. division in an enterprise, customer of a service provider etc.). For certain types of Domains with many users, it will become impractical, to have to individually grant users roles on projects. What is required is for an admin (or Domain admin) to assign users to groups, and then grant those groups roles on projects.

Blueprint information

Joseph Heck
Henry Nash
Henry Nash
Series goal:
Accepted for grizzly
Milestone target:
milestone icon 2013.1
Started by
Joseph Heck on 2012-11-27
Completed by
Joseph Heck on 2013-01-08

Related branches



Here is the classic example:

A Domain is being used to represent a division of an enterprise. They have 20 architects, 100 s/w developers, 20 support engineers and 50 testers. A project is created for each of the 30 s/w projects that are being worked on (all in various stages of their lifecycle), containing the relevant images and VMs.

Use Case Model 1: In this model the enterprise exercises very fine grained control on who can work on which project, assigning individual architects, developers and testers as needed to specific projects.

Use Case Model 2: In this model the enterprise allows staff to move quickly for project to project and wants to grant, say, all developers access to all projects in the dev-stage, all support engineers access to projects in production etc.

Often there might be a mix of the above - a set of general projects and then a few special ones that need unique access.

The current API works fine for the 1st model, but doesn't work at all well for the 2nd - example: if they create a new project they have to individually grant each of the 100 developers a role on it. For the 2nd case, what would be preferable is to allow the creation of groups representing each of the class of users (architects, developers, support, testers) and then grant a role for the group on a project. This way, for a new project, all the admin has to do is grant the roles to the respective groups and if a new developer user is created, all that has to be done is they be added to, in this example, the developer group.

In terms of implementation, the concept of Group would be created (supporting the usual CRUD mechanisms), and, in general, a Group ID could be used wherever a User ID can be supplied today.

Details of the proposed API can be found here:

Etherpad for discussion:

Gerrit topic:,topic:bp/user-groups,n,z

Addressed by:
    Keystone server support for user groups

Gerrit topic:,topic:bug/1092187,n,z


Work Items