<div dir="ltr">Hi Alexander,<div><br></div><div>We - the murano team (so adding [murano] to subj) - are planning to utilise keystone's OAuth flow in Newton timeframe. </div><div><br></div><div>Our use cases require to have ability to delegate some of user's privileges o various kinds of external (i.e. non-openstack) apps or services, so they may interact with Murano API on behalf of that user.</div><div><br></div><div>A real-life example is a Cloud Foundry integration: we have a service which acts as a Cloud Foundry Service Broker [1]: it exposes a CloudFoundry-compatible APIs but under the hood implements them as calls to Murano APIs. So, it needs to authenticate with Keystone using some valid credentials. Right now we use regular user's name and password for that, but this approach is not perfect, since these services may be controlled by third-parties, so the users may not trust them - so, this is the exact use case for the OAuth as a standard.</div><div><br></div><div>Another example of highly demanded use case for murano are custom murano-powered CI/CD pipelines: in such deployments a build server may need to generate murano applications, form murano packages, upload it to package repository (glance/glare) and then deploy that package within an appropriate murano environment. This case also requires this buildserver to call glare and murano APIs on behalf of the user owning the job. We have such deployments right now, but they also are statically configured with the usernames and passwords of some service users, and that's not right. </div><div><br></div><div>So, we are looking forward for OAuth indeed.</div><div><br></div><div>I did some research with the current implementation, it obviously has some issues (including the security ones), but I strongly believe that it should be fixed and improved, not dropped (after all, silently dropping a part of public api should never be an option in openstack: once public - always public). </div><div>If you need my help or feedback on use-cases and found issues - please let me know, I'll be happy to help.</div><div><br></div><div><br></div><div>[1] <a href="http://docs.cloudfoundry.org/services/api.html">http://docs.cloudfoundry.org/services/api.html</a></div><div><br></div><div> </div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 17, 2016 at 1:05 PM Alexander Makarov <<a href="mailto:amakarov@mirantis.com">amakarov@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I'm working on unifying all the models that store actor access rights to the resources [0],</div><div class="gmail_default" style="font-size:small">and now I'm wondering if we can just drop current OAuth1 implementation [1].</div><div class="gmail_default" style="font-size:small">It's definitely not perfect and require considerable effort to bring it in good shape so the question is if the feature worth the attention?</div><div><br></div><div><div class="gmail_default" style="font-size:small">​[0]​ <a href="https://blueprints.launchpad.net/keystone/+spec/unified-delegation" target="_blank">https://blueprints.launchpad.net/keystone/+spec/unified-delegation</a></div><div class="gmail_default" style="font-size:small">[1] <a href="https://github.com/openstack/keystone/tree/master/keystone/oauth1" target="_blank">https://github.com/openstack/keystone/tree/master/keystone/oauth1</a></div><br></div><div>-- <br></div><div><div dir="ltr"><div><div dir="ltr"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Kind Regards,</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Alexander Makarov,</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Senior Software Developer,</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Mirantis, Inc.</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">35b/3, Vorontsovskaya St., 109147, Moscow, Russia</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Tel.: +7 (495) 640-49-04</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Tel.: +7 (926) 204-50-60</font><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><br style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"><font color="#000000" style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">Skype: MAKAPOB.AJIEKCAHDP</font><br></div></div></div></div>
</div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div dir="ltr">Regards,<div>Alexander Tivelkov</div></div>