Support Groups of Users within Keystone
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
- Status:
- Complete
- Approver:
- Joseph Heck
- Priority:
- High
- Drafter:
- Henry Nash
- Direction:
- Approved
- Assignee:
- Henry Nash
- Definition:
- Approved
- Series goal:
- Accepted for grizzly
- Implementation:
-
Implemented
- Milestone target:
-
2013.1
- Started by
- Joseph Heck
- Completed by
- Joseph Heck
Related branches
Related bugs
Sprints
Whiteboard
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:
https:/
Etherpad for discussion: https:/
Gerrit topic: https:/
Addressed by: https:/
Keystone server support for user groups
Gerrit topic: https:/
