Keystone Groups
Use cases:
1. As a cloud customer administrator, I would like to assign and de-assign roles at a group level so that access management becomes easier to handle.
2. As a cloud customer administrator, I would like to create groups that contain users so that I can logically segregate users based on my business needs.
3. As a cloud customer administrator over multiple tenants, I would like to create global groups that can span users of multiple tenants so that I can easily handle the administration functions across those tenants.
Groups should be agnostic of Domains (both allowing groups to exist at the domain level and at the tenant level). This gives ultimate flexibility during implementation and can allow domain-based and tenant-based group functionality.
Logic:
A user may belong to multiple groups.
A group can exist without any users.
There is no limit to the number of users that can belong in a group.
A group connected to a domain is considered a domain-based group.
A group connected to a tenant is considered a tenant-based group.
Blueprint information
- Status:
- Complete
- Approver:
- Ziad Sawalha
- Priority:
- Undefined
- Drafter:
- Joe Savak
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
- Joseph Heck
Related branches
Related bugs
Sprints
Whiteboard
(heck) how is this different from the HP domain's blueprint (https:/
(js) In the domains BP full-specification it was discussed that groups should be split out from domains to allow phased development and customizable installs. Ex: Some private clouds may only have a need for user groups and don't need to worry about cross-domain trust relationships.
