Role assignment to a domain should be more flexible

Registered by Henry Nash

The current v3 API allows the assignment of role to a domain-user pair as well as a project-user pair. In the former case, I believe the intention is that this is interpreted as a request to assign the role in question to all enclosed projects within that domain. However, there may be cases where this is not the desired outcome - for instance a role for which a user is only allowed to CRUD users within that domain (this is the classic requirement for Domain Admins). Initially, only authentication to keystone access itself would honor a domain in the token (now that, in v3, keystone supports RBAC on its own apis), but over time some other projects may wish to do so (e.g. glance so that we can have images that are domain-wide with an administrator suitable permissioned)

The API call for role assignment to a domain should therefore be re-defined to mean assigning a role to the domain container.

Blueprint information

Joseph Heck
Henry Nash
Henry Nash
Series goal:
Accepted for grizzly
Milestone target:
milestone icon 2013.1
Started by
Henry Nash
Completed by
Dolph Mathews

Related branches



David --- surely the situation is more complex than this isnt it? The domain encloses both projects and roles, but not all projects are the same and an administrative user for the domain may not necessarily have the same privileges (i.e. role) for each project. So dont we need to differentiate between:
1. a user being assigned privileges at the domain level (only)
2. a user being assigned privileges for a project (only)
3. a user being assigned the same privileges for all projects in a domain
4. a user being assinged different privileges for different projects in a domain

Shouldnt there be APIs for doing all of these via role assignment?

henry-nash: So I think you can do all the others already - it was just 1) that was missing


Work Items

This blueprint contains Public information 
Everyone can see this information.