Horizon Keystone to Keystone federation

Registered by Doug Fish on 2015-02-20

This blueprint has been superseded. See the newer blueprint "Support K2K Federation on Horizon" for updated plans.

Summary:
Support Keystone to Keystone (K2K) federation in Horizon

Motivation:
Keystone is implementing K2K federation in kilo: https://blueprints.launchpad.net/keystone/+spec/k2k-service-providers
Horizon should be enhanced to take advantage of this capability.

Description:
The approach will be to enhance Horizon to show all of the regions across federated keystone instances. The fact that there are multiple keystones will not be exposed directly in the Horizon UI. Instead the login process will be enhanced to determine the regions across the keystone instances and present a single list of regions. When the user uses the existing Horizon UI element to switch to a different region, updated code will use the proper scoped token obtained from the proper keystone instance.

A scheme will need to be developed to allow for duplicate region names defined in separate keystone instances to be resolved. Possible strategies would be to concatenate keystone-region names, or to add to Horizon configuration to allow a mapping file to be defined to allow Horizon to have a unique nickname for each region.

The implementation will be primarily in django_openstack_auth. It's unclear if the mapping file implementation (if included) will be in horizon itself or django_openstack_auth.

K2K federation is not websso! Although this shares similarities with "Federated Identity via websso" https://blueprints.launchpad.net/horizon/+spec/federated-identity from a Horizon perspective it is almost unrelated. Websso is processing that affects how the initial keystone token is obtained; k2k federation is processing that allows authentication and interaction with multiple keystone instances after obtaining an initial keystone token.

UX:
There are no external UI elements in this design. The intent is to hide the fact there are multiple keystone instances from the Horizon user.

This implementation has been chosen because it's the minimum Horizon implementation of the function, and because it's simple: Horizon users need no new knowledge to interact with federated environments. Feedback should be obtained to determine if this meets the consumer need, or if further work should be done to explicitly expose keystone instances or the keystone/region relationship.

Outside Dependencies:
None

Requirements Update Required:
An updated version of python-keystoneclient will be needed.

Doc Impact:
If a configuration setting is added to Horizon to resolve duplicate names it will need to be documented.

Horizon's behavior when interacting with a k2k federated environment should be documented.

Blueprint information

Status:
Complete
Approver:
David Lyle
Priority:
Medium
Drafter:
Doug Fish
Direction:
Approved
Assignee:
David Lyle
Definition:
Superseded
Series goal:
None
Implementation:
Slow progress
Milestone target:
None
Started by
Rob Cresswell on 2016-04-29
Completed by
David Lyle on 2016-12-16

Related branches

Sprints

Whiteboard

In-review related patches:

https://review.openstack.org/#/c/159910/
https://review.openstack.org/#/c/205251/

[robcresswell 29-04-16]
Changed assignee to David Lyle

(?)

Work Items