Open Stack

On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <martin at millnert.se>
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,
>  2) Go to (for example) "Access & Security / API Access / View
> Credentials" in Horizon, and check out a token from there.
>

With a default configuration, this token would only last a short period of
time, so this would be incredibly repetitive (and thus tedious).

So, I assume you mean some sort of long-lived API tokens? API tokens,
including keystone's UUID, PKI, PKIZ, and Fernet tokens are all bearer
tokens, so we force a short lifetime by default, because there are always
multiple parties capable of compromising the integrity of a token. OAuth
would be a counter example, where OAuth access tokens can (theoretically)
live forever.


>
> 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".
>

The (token) here could be an OAuth access token.


>
> 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160418/08696345/attachment.html>