Bug 1041907

Summary: [RFE][keystone]: Multi-project tokens in Identity API v3
Product: Red Hat OpenStack Reporter: RHOS Integration <rhos-integ>
Component: RFEsAssignee: RHOS Maint <rhos-maint>
Status: CLOSED UPSTREAM QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: markmc, yeylon
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: https://blueprints.launchpad.net/keystone/+spec/multiproject-token-api
Whiteboard: upstream_milestone_none upstream_status_unknown upstream_definition_superseded
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-19 17:25:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

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