[openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation

Martin Millnert martin at millnert.se
Mon Apr 18 16:34:03 UTC 2016


we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2
Federation system by Keystone where we're a Service Provider (SP).

The problem in this situation is getting a token for direct API

There are conceptually two methods to use the CLI:
 1) Modify ones (each customer -- in our case O(100)) IdP to add support
for a feature called ECP(**), and then use keystoneauth with SAML2
 2) Go to (for example) "Access & Security / API Access / View
Credentials" in Horizon, and check out a token from there.

2) isn't implemented. 1) is a complete blocker for many customers.

Are there any principal and fundamental reasons why 2 is not doable?
What I imagine needs to happen:
  A) User is authenticated (see *) in Horizon,
  B) User uses said authentication (token) to request another token from
Keystone, which is displayed under the "API Access" tab on "Access &

>From a general perspective, I can't see why this shouldn't work.

Whatever scoping the user currently has should be sufficient to check
out a similarly-or-lesser scoped token.

Anyway, we will, if this is at all doable, bolt this onto our local
deployment. I do, A) believe we're not alone with this use case (***),
B) look for input on doability.

We'll be around in Austin for discussion with Horizon/Keystone regarding
this if necessary.

Martin Millnert

(* The reason this is a problem: With Federation, there are no local
users and passwords in the Keystone database. When authenticating to
Horizon in this setup, Keystone (I think) redirects the user to an HTTP
page on the home site's Identity Provider (IdP), which performs the
authentication. The IdP then signs a set of entitlements about this
identity, and sends these back to Keystone. Passwords stay at home. Epic

(** ECP is a new feature, not supported by all IdP's, that at (second)
best requires reconfiguration of core authentication services at each
customer, and at worst requires customers to change IdP software
completely. This is a varying degree of showstopper for various


More information about the OpenStack-dev mailing list