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