<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 05/12/2016 09:07 AM, Edmund Rhudy
(BLOOMBERG/ 120 PARK) wrote:<br>
</div>
<blockquote cite="mid:5734801B01F405BE003903CE_0_50851@p057"
type="cite">
<title></title>
<!-- rte-version 0.2 9947551637294008b77bce25eb683dac -->
<div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width">+1 on desiring OAuth-style tokens in Keystone. The use cases that come up here are people wanting to be able to execute jobs that use the APIs (Jenkins, Terraform, Vagrant, etc.) without having to save their personal credentials in plaintext somewhere, and also wanting to be able to associate credentials with a project instead of a specific person, so that if a person leaves or rotates their password it doesn't blow up their team's carefully crafted automation.<div>
</div><div>We can sort of work around it with LDAP service accounts as mentioned previously, but the concern around those is the lack of speedy revocability in the event of a compromise, and the service accounts could possibly be used to get to non-OpenStack places until they get shut down. One thought I had to try to keep the auth domain constrained to only OpenStack was using the EC2 API because at least that means you're not saving LDAP passwords on disk and the access keys are useless beyond that particular Keystone installation, but you run into impedance mismatches between the Nova API and AWS EC2 API, and we'd like people to use the native OpenStack APIs. (Turns out the notion of using AWS's EC2 API to talk to a private cloud is strange to people not steeped in cloudy things.)
</div></div>
</blockquote>
So Service accounts and OAuth consumers are two different names for
the same abstract construct. IN both cases, the important thing is
limiting the access each one has.<br>
<br>
<br>
Horizon is for the interactive use case, though, and should not be
using either, except as a front to define workflows, and in that
case, the same work should be possible from the command line.<br>
<br>
ECP should make that possible, assuming your IdP supports ECP
(EIEIO!).<br>
<br>
<br>
<br>
<blockquote cite="mid:5734801B01F405BE003903CE_0_50851@p057"
type="cite">
<div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><div><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width">
<div class="bbg-rte-fold-content" data-header="From: openstack-dev@lists.openstack.org" data-digest="From: openstack-dev@lists.openstack.org" style=""><div class="bbg-rte-fold-summary">From: <a class="moz-txt-link-abbreviated" href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a> </div><div>Subject: Re: [openstack-dev] [horizon][keystone] Getting Auth Token from Horizon when using Federation
</div></div><blockquote>Hi Dolph,
On Mon, 2016-04-18 at 17:50 -0500, Dolph Mathews wrote:
>
> On Mon, Apr 18, 2016 at 11:34 AM, Martin Millnert <<a moz-do-not-send="true" spellcheck="false" bbg-destination="mailto:rte:bind" href="mailto:martin@millnert.se" data-destination="mailto:rte:bind">martin@millnert.se</a>>
> 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).
</blockquote></div></div></div>
</blockquote>
Assuming all that is setup, the user should be unaware of the
re-init to the SAML IdP to get a new assertion for a new token. Why
is this a problem?<br>
<br>
<br>
<blockquote cite="mid:5734801B01F405BE003903CE_0_50851@p057"
type="cite">
<div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><div><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><blockquote>
Indeed.
> So, I assume you mean some sort of long-lived API tokens?
Right.
> 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.
</blockquote></div></div></div>
</blockquote>
<br>
Still think that is a security violation.<br>
<br>
<br>
<blockquote cite="mid:5734801B01F405BE003903CE_0_50851@p057"
type="cite">
<div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><div><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><blockquote>
This does sound very interesting. As long as the end user gets something
useful to plug into the openstack auth libraries/APIs, we're home free
(modulo security considerations, etc).
> 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.
Will look into this (also as per our discussion in Austin).
The one issue that has appeared in our continued discussions at home, is
the contrast against "service user accounts", that seems a relatively
prevalent/common among deployers today, which basically use
username/password as the api key credentials, e.g. the authZ of the
issued token:
If AdminNameless is Domain Admin in their domain, won't their OAuth
access token yield keystone tokens with the same authZ as they otherwise
have?
My presumptive answer being 'yes', brought me to the realization that,
if one wants to avoid going the way of "service user accounts" but still
reduce authZ, one would like to be able to get OAuth access tokens for a
specific project, with a specific role (e.g. "user", or [project-]admin)
and the authZ this entails. This would keep the traceability, which is
one of the main issues with non-personal accounts.
</blockquote></div></div></div>
</blockquote>
<br>
I don't think end users should be able to do this themselves. If I
lose my access to the IdP due to getting fired, my OAuth tokens
should no longer be valid, either. But there is no consistent way
to communicate this information.<br>
<br>
<blockquote cite="mid:5734801B01F405BE003903CE_0_50851@p057"
type="cite">
<div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><div><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><blockquote>
How feasible is this last bit?
In general, the primary use case is:
- I as a user of openstack on my personal computer retrieve a token to
manage openstack client operations without the need of storing my
Federation-username/password in local config (nor typing the password in
on the keyboard).
An extended use case definition of this being:
- I as a user of openstack can provision an automated system with these
credentials, that can continue to operate as an openstack client for a
very long time without maintenance (i.e., either token renewal or
VeryLongLifetime).
</blockquote></div></div></div>
</blockquote>
<br>
You can build all sorts of things that look like secure
authentication without actually being secure authentication.
Federation assumes that the IdP is the true voice of authority.
OAuth and service users both assume they are getting authority
delegated to them fomr the end users. So, without SAML assertions
confirming that authority, you will end up with no way to either
confirm or deny. Are you OK with that restriction?<br>
<br>
<blockquote cite="mid:5734801B01F405BE003903CE_0_50851@p057"
type="cite">
<div class="rte-style-maintainer" style="white-space: pre-wrap; font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><div><div class="rte-style-maintainer" style="font-size: small; font-family: 'Courier New', Courier; color: rgb(0, 0, 0);" data-color="global-default" bbg-color="default" data-bb-font-size="medium" bbg-font-size="medium" bbg-font-family="fixed-width"><blockquote>
Best,
Martin
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a moz-do-not-send="true" spellcheck="false" bbg-destination="mailto:rte:bind" href="mailto:OpenStack-dev-request@lists.openstack.org" data-destination="mailto:rte:bind">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe
<a moz-do-not-send="true" bbg-destination="rte:bind" spellcheck="false" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" data-destination="rte:bind">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</blockquote>
</div></div></div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>