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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
