On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <mar...@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-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