Open Stack

Excerpts from Kristi Nikolla's message of 2017-03-15 12:35:45 -0400:
> This might be related to the current discussion. 
> 
> In one of the keystone PTG sessions we started to talk about API keys. [0]
> A spec is being written and discussed. [1]
> 
> This would allow the user to provision API key credentials with a subset of roles for use inside of their applications. Removing the need to inject the actual user credentials inside an application.
> 
> [0] http://lbragstad.com/keystone-pike-ptg-summary/
> [1] https://review.openstack.org/#/c/438761
> 

 ^^ this!

> > On Mar 15, 2017, at 8:45 AM, Sean Dague <sean at dague.net> wrote:
> > 
> > On 03/13/2017 05:10 PM, Zane Bitter wrote:
> >> 
> >> Demo please!
> >> 
> >> Most Keystone backends are read-only, you can't even create a new user
> >> account yourself. It's an admin-only API anyway. The only non-expiring
> >> credential you even *have*, ignoring the difficulties of getting it to
> >> the server, is your LDAP password. Would *you* put *your* LDAP password
> >> on an internet-facing server? I would not.
> > 
> > So is one of the issues to support cloud native flows that our user auth
> > system, which often needs to connect into traditional enterprise
> > systems, doesn't really consider that?
> > 
> > I definitely agree, if your cloud is using your LDAP password, which
> > gets you into your health insurance and direct deposit systems at your
> > employeer, sticking this into a cloud server is a no go.
> > 
> > Thinking aloud, I wonder if user provisionable sub users would help
> > here. They would have all the same rights as the main user (except
> > modify other subusers), but would have a dedicated user provisioned
> > password. You basically can carve off the same thing from Google when
> > you have services that can't do the entire oauth/2factor path. Fastmail
> > rolled out something similar recently as well.
> > 
> >     -Sean
> > 
> > -- 
> > Sean Dague
> > http://dague.net
> > 
> > __________________________________________________________________________
> > 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
>