Bug 1041907 - [RFE][keystone]: Multi-project tokens in Identity API v3
Summary: [RFE][keystone]: Multi-project tokens in Identity API v3
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: RFEs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Maint
QA Contact:
URL: https://blueprints.launchpad.net/keys...
Whiteboard: upstream_milestone_none upstream_stat...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-12 20:00 UTC by RHOS Integration
Modified: 2015-03-19 17:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-19 17:25:43 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description RHOS Integration 2013-12-12 20:00:54 UTC
Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/multiproject-token-api.

Description:

Background:
The XML spec for the v2.0 API allows more than 1 tenant (project) per token, but the JSON API & keystone/keystoneclient implementation do not. This blueprint resolves that conflict by specifically allowing multiproject tokens throughout the API, without impacting OpenStack as a whole.

API Impact:
- API support for authenticating with a list of projects instead of a single tenantId/tenantName as seen in v2.0
- API support for returning a list of projects a token applies to on token validation, instead of a single project as currently specified
- API support for remote token validation against a list of projects, e.g. HEAD /tokens?project_ids={tenant_id1},{tenant_id2} (as compared to HEAD /tokens/{token_id}?belongsTo={tenant_id1} in v2.0)

Implementation Impact (openstack services continue to be limited to single-project tokens):
- keystone can raise 501 Not Implemented if it receives an auth request for more than one project.
- auth_token middleware can raise 501 Not Implemented if it receives a token with more than one project.
- keystoneclient must appropriately handle a list of projects for all applicable calls (auth, validation)

This impact of this blueprint is limited to keystone; without the above 501's, the auth_token middleware contract with underlying services would also be required to support multiple projects (a backwards incompatible change), and backwards-compatibility with the v2.0 Admin API could not be maintained (the v2.0 JSON API could not validate a multiproject v3 token via a GET).

Specification URL (additional information):

None


Note You need to log in before you can comment on or make changes to this bug.