[openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation
ayoung at redhat.com
Tue Apr 19 01:48:48 UTC 2016
On 04/18/2016 12:34 PM, Martin Millnert wrote:
> 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
We have this working. Your SAML provider might not. What Are you
> 2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
Insecure as all get out. Please no.
> 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.
Let me explain. A Token is a symmetric shared secret. You should not
be copyuing it around, etc. You don't make it readable in a Web UI.
You control it, and ideally, never let it see the light of day.
> 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
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev