support domain scoped user project domain rbac
Summary
=======
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.
Motivation
==========
Keystone v3 supports multi-domain configurations. Part of the motivation of domains is being able to enable compartmentaliz
Description
=========
In a pre-requisite blueprint, django_
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.
UX
===
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
-------
N/A
Testing
======
In order to test these changes, there are a couple of settings changes required in local/local_
OPENSTACK_
"identity": 3,
}
OPENSTACK_
To fully test the domain admin functionality, the v3 policy file will need to be copied to openstack_
Outside Dependencies
=======
Support obtaining a domain scoped token in django_
This functionality will need to be released and the minimum version of django_
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_
Doc Impact
=========
The doc impact of this change will be to the overall openstack documentation regarding domain management.
[1] https:/
[2] https:/
Blueprint information
- Status:
- Complete
- Approver:
- David Lyle
- Priority:
- High
- Drafter:
- Yaguang Tang
- Direction:
- Approved
- Assignee:
- David Lyle
- Definition:
- Approved
- Series goal:
- Accepted for mitaka
- Implementation:
- Implemented
- Milestone target:
- None
- Started by
- David Lyle
- Completed by
- David Lyle
Related branches
Related bugs
Sprints
Whiteboard
[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_
[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] https:/
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.