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 > On Mar 15, 2017, at 8:45 AM, Sean Dague <s...@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-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
