Add support for domain scoped tokens

Registered by David Lyle

In order to fully support the management of identity in keystone v3 when using a richer role set, a domain scoped token is required. django_openstack_auth needs to support obtaining and maintaining this type of token on the session.

There are two scenarios to support:
1) the user has a role only on a domain
     In this case, when the user logs in, they obtain a domain scoped token and that is saved in the user's session.
2) the user has a role on a domain and a role on a project in that domain
     In this case, when the user logs in, they obtain a domain scoped token and a project scoped token for a project in the domain scoped in the domain scoped token. Both tokens are stored in the user's session.

This functionality will only be visible when keystone v3 is the API version AND multi-domain support is enabled in the settings file.

Required settings changes:

     "identity": 3,


Blueprint information

David Lyle
David Lyle
David Lyle
Series goal:
Accepted for liberty
Milestone target:
Started by
David Lyle
Completed by
David Lyle

Related branches



Gerrit topic:,topic:bp/domain-scoped-tokens,n,z

Addressed by:
    Add domain scoped token to session in multidomain

[esp 2015.01.08] Note that this implementation requires the django session to be backed by memcached or a datastore that can handle the size of the additional domain scoped token and v3 catalog.

The tripleo horizon configs reference memcached as the session_engine.

Openstack docs also describe using these settings for production deployments.

Horizon Tasks (from conversations with DL)

General Prerequisites:
1. Setup memcached and install the appropriate python client library described in the openstack documentation.
[drf 2015.02.25] I assume this isn't explicitly tied to memcached -- database or most others should work as well. I think the point is no cookie backed sessions, right? Edited: okay, I see that's true, just noting again here so if this is the source for documentation is gets spelled out.

2. Configure to
   - Use memcached as the session_engine
   - Use keystone v3 with multi-domain support set to True

3. Download the patch in progress for setting the domain scoped token in the session in DOA.

TODO 1. Make sure project dash doesn't blow up in the case of no project token (DL suspects it will)
Catalog is present in both token types, but roles are not the same
There will be work on the django-openstack-auth patch to handle no project role
There will be impact to horizon as well

TODO 2. For pure domain admins, need to hide project dash
Hide the project dashboard based on pure domain admin role (because of 1, no project dash)
There are only 2-3 panels that don't hide now

Wire up api/ to use domain scoped token when present and multi-domain support turned on

TODO 4. Rework the data access calls to use policy checks
The projects/ does that now

TODO 5. Using the v3 policy file, wire up the RBAC appropriately in the identity dashboard

In the views, workflows, forms, etc in the identity dash there is more work around RBAC (what's there hasn't been exercised with the v3 policy file)

Will need to test with various users and roles.

Gerrit topic:,topic:bp/s,n,z

Addressed by:
    Allow logins when not member of a project

[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 thus is unable to see domain resources across projects unless the 'admin' role is added for the user on one of the projects. Additionally, there is a lack of drive to utilize/understand domains in other services.

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

Addressed by:
    Makes policy.check aware of domain scoped token


Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.