Support K2K Federation on Horizon

Registered by Elvin Tubillara

Support Keystone to Keystone (K2K) federation in Horizon
This blueprint is meant to replace:

Keystone has supported K2K federation since Kilo. Users should be able
to use Horizon can take advantage of this feature. This blueprint was made
to replace the previous blueprint with the following motivations:
Reduce required session space so that client side cookies (that store
session variables) can be used (<4kb).

This blueprint enables horizon to utilize Keystone to Keystone (K2K) Federation.
The K2K auth uses SAML ECP to federate identity across keystones.
It is a client based protocol and not WebSSO.

The main difference between this blueprint and the former (See above) is that
this will add an additional UI element where the service provider
Keystone is selected and displayed. This will be seperate from

We want to add a service provider drop down on the horizon top bar. The user
would be able to select their service provider.

When a user first signs in, K2K authentication will not be used but the
normal password and token authentication. If there are available
service providers(given by keystone token access info),
a selection bar at the top page will appear.

The base unscoped token for the identity provider will be stored.
During log in the list for service providers will be retreived from
the scoped access info object.

A user can switch Keystone providers by clicking on the selection
bar at the top left of the screen.

Horizon will attempt to connect to the selected keystone by using
K2K authentication. If it can't an error message will pop up. Otherwise
the user will effectively follow the process of being logged out
and logged into the next Keystone.
Since the base unscoped token for the identity provider has been stored,
this allows the user to be able to log into the other service providers.

What this implementation supports is that there is one identity provider
Keystone which enables authentication to the other service providers.
What this implies is that if we have an identity provider Keystone A,
and a service provider B, A can be used to authenticate into B.
But it might also be the case that B could be an identity provider
and A be the service provider. You can only choose one to be
the identity provider.
This also implies that if A is an identity provider for B and B is
an identity provider for C, you cannot authenticate from A to B to C
using this implementation. Supporting such a feature in Horizon
would be confusing for the user.

A new dropdown will be created in the OpenStack dashboard that will
be used to select which Keystone to connect to.
Keystone Provider: <Keystone Provider Name>

Outside Dependencies:

Requirements Update Required:

Doc Impact:
Documentation will be made to explain what this feature is.

Blueprint information

David Lyle
Elvin Tubillara
Elvin Tubillara
Series goal:
Accepted for 11.0.0-ocata
Milestone target:
milestone icon ocata-3
Started by
Rob Cresswell
Completed by
Rob Cresswell

Related branches



[david-lyle | 2016-11-17] I'm happy to see this move forward in this format.
Additional considerations that were considered:
* Reusing the endpoint selector rather than a new control. I think there are a couple of problems with that approach. One is it's built on a hardcoded list in settings not from token content which is a downside. Two is the mechanics may be a bit different.
* Having a drop-down on the login page was a suggestion from an operator as potentially logging into the wrong keystone could incur charges. I don't think that blocks the usefulness of this approach and can be considered separately.

Gerrit topic:,topic:bp/k2k-horizon,n,z

Addressed by:
    WIP Keystone to Keystone Federation Drop Down


Work Items

This blueprint contains Public information 
Everyone can see this information.