<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 19, 2016 at 6:51 PM, Adam Young <span dir="ltr"><<a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <div>On 06/16/2016 02:19 AM, Jamie Lennox
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>Thanks everyone for your input. <br>
                      <br>
                    </div>
                    I generally agree that there is something that
                    doesn't quite feel right about purely trusting this
                    information to be passed from service to service,
                    this is why i was keen for outside input and I have
                    been rethinking the approach. <br>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></span>
    They really feel like a variation on Trust tokens.<br>
    <br>
    From the service perspective, they are tokens, just not the one the
    user originally requested.<br>
    <br>
    The "reservation" as I see it is an implicit trust created by the
    user requesting the operation on the initial service.<br>
    <br>
    When the service validates the token, it can get back the,  lets
    call it a "reserved token" in keeping with the term reservation
    above.  That token will have a longer life span than the one the
    user originally requested, but (likely) fewer roles.  <br>
    <br>
    When nova calls glance, and then glance calls Swift, we can again
    transition to different reserved tokens if needs be.<span class=""><br>
    <br>
    <br></span></div></blockquote><div><br></div><div>I would really, really, really, prefer not to build in the need to "transition" between "reserved" tokens when jumping between services. This wont be "impossible", but I really don't want to start from the simpler proposal; It's a lot of moving parts.</div><div><br></div><div>The big difference here is that trusts are explicit and have a LOT of overhead (and frankly would be clunky for this) as currently implemented, this is closer to an evolved version of the composite tokens we talked over in Paris.</div><div><br></div><div>--Morgan</div><div> <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div><br>
                  </div>
                  To this end i've proposed reservations (a name that
                  doesn't feel right): <a href="https://review.openstack.org/#/c/330329/" target="_blank">https://review.openstack.org/#/c/330329/</a><br>
                  <br>
                </div>
                At a gut feeling level i'm much happier with the
                concept. I think it will allow us to handle the
                distinction between user->service and
                service->service communication much better and has
                the added bonus of potentially opening up some policy
                options in future. <br>
                <br>
              </div>
              Please let me know of any concerns/thoughts on the new
              approach.<br>
              <br>
            </div>
            Once again i've only written the proposal part of the spec
            as there will be a lot of details to figure out if we go
            forward. It is also fairly rough but it should convey the
            point. <br>
            <br>
            <br>
          </div>
          Thanks <br>
          <br>
        </div>
        Jamie<br>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On 3 June 2016 at 03:06, Shawn McKinney
          <span dir="ltr"><<a href="mailto:smckinney@symas.com" target="_blank">smckinney@symas.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
              > On Jun 2, 2016, at 10:58 AM, Adam Young <<a href="mailto:ayoung@redhat.com" target="_blank"></a><a href="mailto:ayoung@redhat.com" target="_blank">ayoung@redhat.com</a>>
              wrote:<br>
              ><br>
              > Any senseible RBAC setup would support this, but we
              are not using a sensible one, we are using a hand rolled
              one. Replacing everything with Fortress implies a complete
              rewrite of what we do now.  Nuke it from orbit type stuff.<br>
              ><br>
              > What I would rather focus on is the splitting of the
              current policy into two parts:<br>
              ><br>
              > 1. Scope check done in code<br>
              > 2. Role check done in middleware<br>
              ><br>
              > Role check should be donebased on URL, not on the
              policy key like identity:create_user<br>
              ><br>
              ><br>
              > Then, yes, a Fortress style query could be done, or
              it could be done by asking the service itself.<br>
              <br>
            </span>Mostly in agreement.  I prefer to focus on the model
            (RBAC) rather than a specific impl like Fortress. That is to
            say support the model and allow the impl to remain
            pluggable.  That way you enable many vendors to participate
            in your ecosystem and more important, one isn’t tied to a
            specific backend (ldapv3, sql, …)<br>
            <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>
              </div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </span></div>

<br>__________________________________________________________________________<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>
<br></blockquote></div><br></div></div>