[openstack-dev] [tc][appcat] The future of the App Catalog
kristi at nikolla.me
Wed Mar 15 16:35:45 UTC 2017
This might be related to the current discussion.
In one of the keystone PTG sessions we started to talk about API keys. 
A spec is being written and discussed. 
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.
> 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 Dague
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev