<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 03/25/2016 08:44 AM, Alexander
      Tivelkov wrote:<br>
    </div>
    <blockquote
cite="mid:CAM6FM9Tkt90vwq5=K6i-EVRip3G43vGZkBwV8KyFxOMsR-n1Jw@mail.gmail.com"
      type="cite">
      <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>
    </blockquote>
    <br>
    This is good to know, and exactly what the API was designed for.  We
    are looking to unify the implementation with how we do Trusts and
    Role Assignments, but we will not be changing the semantics.  We
    just were hoping to avoid the work for OAUTH if it was not being
    used.<br>
    <br>
    <blockquote
cite="mid:CAM6FM9Tkt90vwq5=K6i-EVRip3G43vGZkBwV8KyFxOMsR-n1Jw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div>[1] <a moz-do-not-send="true"
            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 moz-do-not-send="true"
              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 moz-do-not-send="true"
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
                    moz-do-not-send="true"
                    href="https://github.com/openstack/keystone/tree/master/keystone/oauth1"
                    target="_blank"><a class="moz-txt-link-freetext" href="https://github.com/openstack/keystone/tree/master/keystone/oauth1">https://github.com/openstack/keystone/tree/master/keystone/oauth1</a></a></div>
                <br>
              </div>
              <div>-- <br>
              </div>
              <div>
                <div dir="ltr">
                  <div>
                    <div dir="ltr"><font
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">Kind Regards,</font><br
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">
                      <font
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">Alexander Makarov,</font><br
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">
                      <font
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">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
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">Mirantis, Inc.</font><br
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">
                      <font
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">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
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">Tel.: +7 (495) 640-49-04</font><br
style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px">
                      <font
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">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
                        style="color:rgb(0,0,0);font-family:Cantarell;font-size:15px"
                        color="#000000">Skype: MAKAPOB.AJIEKCAHDP</font><br>
                    </div>
                  </div>
                </div>
              </div>
            </div>
__________________________________________________________________________<br>
            OpenStack Development Mailing List (not for usage questions)<br>
            Unsubscribe: <a moz-do-not-send="true"
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 moz-do-not-send="true"
              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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>