<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 14, 2017 at 6:59 PM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 05/11/2017 02:32 PM, Lance Bragstad wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hey all,<br>
<br>
One of the Baremetal/VM sessions at the summit focused on what we need<br>
to do to make OpenStack more consumable for application developers [0].<br>
As a group we recognized the need for application specific passwords or<br>
API keys and nearly everyone (above 85% is my best guess) in the session<br>
thought it was an important thing to pursue. The API<br>
key/application-specific password specification is up for review [1].<br>
<br>
The problem is that with all the recent churn in the keystone project,<br>
we don't really have the capacity to commit to this for the cycle. As a<br>
project, we're still working through what we've committed to for Pike<br>
before the OSIC fallout. It was suggested that we reach out to the PWG<br>
to see if this is something we can get some help on from a keystone<br>
development perspective. Let's use this thread to see if there is anyway<br>
we can better enable the community through API keys/application-specific<br>
passwords by seeing if anyone can contribute resources to this effort.<br>
</blockquote>
<br></span>
In the session, I signed up to help get the spec across the finish line. I'm also going to do my best to write up something resembling a user story so that we're all on the same page about what this is, what it isn't and what comes next.<br>
<br>
I probably will not have the time to actually implement the code - but if the PWG can help us get resources allocated to this I'll be happy to help them.<br></blockquote><div>If anyone's counting, here are the current open specs (that I've found) that attempt to address, in slightly different ways, the slightly different use cases for API keys (not including the open specs to overhaul policy):</div><div><br></div><div> - <a href="https://review.openstack.org/#/c/186979">https://review.openstack.org/#/c/186979</a> - Subset tokens</div> - <a href="https://review.openstack.org/#/c/389870">https://review.openstack.org/#/c/389870</a> - Adding user credentials and delegating role assignments to credential types<div> - <a href="https://review.openstack.org/#/c/396634">https://review.openstack.org/#/c/396634</a> - Standalone trusts</div><div> - <a href="https://review.openstack.org/#/c/440593">https://review.openstack.org/#/c/440593</a> - API keys</div><div> - <a href="https://review.openstack.org/#/c/450415">https://review.openstack.org/#/c/450415</a> - Application keys</div><div><br></div><div>Additionally, I think OAuth - either extending the existing OAuth1.0 plugin or implementing OAuth2.0 - should probably be on the table.</div><div><br></div><div>Colleen</div></div></div></div>