support domain scoped user project domain rbac

Registered by Yaguang Tang

Keystone v3 has supported multi-domain configurations since Grizzly. Horizon needs to add support for domain scoped tokens and their use to expose this functionality.

Keystone v3 supports multi-domain configurations. Part of the motivation of domains is being able to enable compartmentalization of resources. To make full use of this isolation, it's desirable to provide users administrative rights over just one domain, but not the whole stack. A finer granularity of roles is required to do this. For example, an administrator over an individual domain should be able to add new users, create projects and assign roles to users inside the domain they administer. To support these actions Horizon needs to support maintaining domain scoped tokens which are required to complete these actions and use them in the appropriate situations.

In a pre-requisite blueprint, django_openstack_auth will manage obtaining and storing the domain scoped token on the session where the configuration necessitates it. There are three use cases handled when domain scoped tokens are involved.
1) The user only has a role on the domain.
   -- In this case, the user will log in and obtain only a domain scoped token. There will be no other services in the user's service catalog and they will only have visibility to the Identity dashboard. Their access to read/update in that dashboard will be determined by RBAC.
2) The user has a role on the domain and a project(s) in that domain
   -- In this case, the user log in and obtain two tokens, both are stored on the session.
     * For the identity dashboard, the domain scoped token is used to make API calls. Their access to read/update in that dashboard will be determined by RBAC.
    * For the other dashboards, the project scoped token is used to make API calls to all services.
3) The user has only a role on a project(s) in a domain
   -- In this case, Horizon behaves as it does today.

Additional work will need to be done to make sure that richer policy files [2] are supported in the Identity dashboard.

The nature of this change is wiring in Horizon. The end user experience should be unaffected other than enabling Identity management at the domain level when using a richer policy file [2]. All views already exist.

Wireframes, Mocks, Videos and UI Markup

In order to test these changes, there are a couple of settings changes required in local/

     "identity": 3,


To fully test the domain admin functionality, the v3 policy file will need to be copied to openstack_dashboard/conf/keystone_policy.json as well.

Outside Dependencies
Support obtaining a domain scoped token in django_openstack_auth
This functionality will need to be released and the minimum version of django_openstack_auth in openstack/requirements updated to that released version.

The functionality has existed in Keystone since Grizzly.

Sample v3 policy file for Keystone [2] will be used for reference and support testing.

Requirements Update Required
See above requirement to release and update version of django_openstack_auth.

Doc Impact
The doc impact of this change will be to the overall openstack documentation regarding domain management.


Blueprint information

David Lyle
Yaguang Tang
David Lyle
Series goal:
Accepted for mitaka
Milestone target:
Started by
David Lyle
Completed by
David Lyle

Related branches



[david-lyle 2014.09.08] Domain administration in keystone requires a domain scoped token. The majority of the work for this blueprint will take place in django_openstack_auth where a domain scoped token and a project scoped token should both be maintained. The work in Horizon will be passing the correct token when attempting to administer domains.

[bpokorny 2014.11.14] Very complete blueprint. The solution makes sense to me. The only thing I'd suggest is putting a reference to [1] into the Description section.

[doug-fish 2014.11.20] What token will be used for panels in the Admin dashboard? Those panels show cross-project information, but this blueprint leads me to believe that a project token will be used. Is that right?

I'm confused about why a domain scoped token is used only on the Identity dashboard. I'm open to being directed to other reading.

[bpokorny 2014.11.20] doug-fish: Good questions. I think the solution this blueprint describes is not so much Admin dashboard vs. non-Admin dashboards, but is more about using the correct type of token (domain scoped or project scoped) with the correct API version.

For services that use the v3 and above API (currently only possible for keystone), domain scoped tokens need to be used to validate a user's access in a domain. Services that still use the v2 and lower API don't yet understand domains, so still need to be used with project scoped tokens.

This solution allows Horizon to use a domain scoped token when talking to the v3 Identity API (such as listing projects via keystone) but use a project scoped token when talking to all the other OpenStack components (which are currently incapable of understanding v3).

[tsufiev 2014.11.26] A stupid question: is it possible to change domain of a project? If yes, how this situation is going to be handled when it changes after the user has logged in?

[amotoki Nov 27, 2014] Looks good. Kilo-2 seems a reasonable target since most required work is in the openstack_auth side.

[esp Jan 13, 2015]
This wiki describes how to test David's patch in DOA and find the gaps left to implement in horizon.
The wiki is still a work in progress.

[david-lyle | 2015-03-16] This is a fools errand. I'm removing from Kilo. At the beginning of Kilo, keystone indicated this would be the forward direction, it is not. I don't believe this method will actually ever work as intended. Other services are unaware of different token types and treat 'admin' role as just that. So a domain 'admin' takes on overall 'admin' role in other services that are token type unaware. Due to this large security hole, and the lack of drive to utilize/understand domains in other services, I'm going to stop efforts on this. I see no acceptable path forward.

Hierarchical Projects, with a unified token type may solve these issues, but that will be only be determined in Liberty or later.

RIP domains and v3 policy.

[david-lyle | 2016-05-04] Turns out they wouldn't die and we finally merged this support in Mitaka.


Work Items

Dependency tree

* Blueprints in grey have been implemented.