Open Stack

On 04/18/2016 12:34 PM, Martin Millnert wrote:
> Hi,
>
> 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
> access.(*)
>
> 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
> plugin,
We have this working.  Your SAML provider might not.  What Are you 
working with?


>   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 &
> Security".
>
>  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.
>
> Regards,
> 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
> Win.)
>
> (** 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
> customers.)
>
> (***
> https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon
> https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/
> )
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev