<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <span dir="ltr"><<a href="mailto:martin@millnert.se" target="_blank">martin@millnert.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
we're deploying Liberty (soon Mitaka) with heavy reliance on the SAML2<br>
Federation system by Keystone where we're a Service Provider (SP).<br>
<br>
The problem in this situation is getting a token for direct API<br>
access.(*)<br>
<br>
There are conceptually two methods to use the CLI:<br>
 1) Modify ones (each customer -- in our case O(100)) IdP to add support<br>
for a feature called ECP(**), and then use keystoneauth with SAML2<br>
plugin,<br>
 2) Go to (for example) "Access & Security / API Access / View<br>
Credentials" in Horizon, and check out a token from there.<br></blockquote><div><br></div><div>With a default configuration, this token would only last a short period of time, so this would be incredibly repetitive (and thus tedious).</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) isn't implemented. 1) is a complete blocker for many customers.<br>
<br>
Are there any principal and fundamental reasons why 2 is not doable?<br>
What I imagine needs to happen:<br>
  A) User is authenticated (see *) in Horizon,<br>
  B) User uses said authentication (token) to request another token from<br>
Keystone, which is displayed under the "API Access" tab on "Access &<br>
Security".<br></blockquote><div><br></div><div>The (token) here could be an OAuth access token.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>From a general perspective, I can't see why this shouldn't work.<br>
<br>
Whatever scoping the user currently has should be sufficient to check<br>
out a similarly-or-lesser scoped token.<br>
<br>
Anyway, we will, if this is at all doable, bolt this onto our local<br>
deployment. I do, A) believe we're not alone with this use case (***),<br>
B) look for input on doability.<br>
<br>
We'll be around in Austin for discussion with Horizon/Keystone regarding<br>
this if necessary.<br>
<br>
Regards,<br>
Martin Millnert<br>
<br>
(* The reason this is a problem: With Federation, there are no local<br>
users and passwords in the Keystone database. When authenticating to<br>
Horizon in this setup, Keystone (I think) redirects the user to an HTTP<br>
page on the home site's Identity Provider (IdP), which performs the<br>
authentication. The IdP then signs a set of entitlements about this<br>
identity, and sends these back to Keystone. Passwords stay at home. Epic<br>
Win.)<br>
<br>
(** ECP is a new feature, not supported by all IdP's, that at (second)<br>
best requires reconfiguration of core authentication services at each<br>
customer, and at worst requires customers to change IdP software<br>
completely. This is a varying degree of showstopper for various<br>
customers.)<br>
<br>
(***<br>
<a href="https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon" rel="noreferrer" target="_blank">https://stackoverflow.com/questions/20034143/getting-auth-token-from-keystone-in-horizon</a><br>
<a href="https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/" rel="noreferrer" target="_blank">https://ask.openstack.org/en/question/51072/get-keystone-auth-token-via-horizon-url/</a><br>
)<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>