<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 7, 2014 at 3:05 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"><div class="">
    <div>On 07/07/2014 11:11 AM, Dolph Mathews
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Fri, Jul 4, 2014 at 5:13 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Unscoped
              tokens are really a proxy for the Horizon session, so lets
              treat them that way.<br>
              <br>
              <br>
              1.  When a user authenticates unscoped, they should get
              back a list of their projects:<br>
              <br>
              some thing along the lines of:<br>
              <br>
              domains [{   name = d1,<br>
                               projects [ p1, p2, p3]},<br>
                             {   name = d2,<br>
                               projects [ p4, p5, p6]}]<br>
              <br>
              Not the service catalog.  These are not in the token, only
              in the response body.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Users can scope to either domains or projects, and we
              have two core calls to enumerate the available scopes:</div>
            <div><br>
            </div>
            <div>  GET /v3/users/{user_id}/projects</div>
            <div>  GET /v3/users/{user_id}/domains<br>
            </div>
            <div><br>
            </div>
            <div>There's also `/v3/role_assignments` and
              `/v3/OS-FEDERATION/projects`, but let's ignore those for
              the moment.<br>
            </div>
            <div><br>
            </div>
            <div>You're then proposing that the contents of these two
              calls be included in the token response, rather than
              requiring the client to make a discrete call - so this is
              just an optimization. What's the reasoning for pursuing
              this optimization?</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    It is a little more than just an optimization.  <br>
    <br>
    An unscoped token does not currently return a service catalog, and
    there really is no need for it to do so if it is only ever going to
    be used to talk to keystone.  Right now, Horizon cannot work with
    unscoped tokens, as you need a service catalog in order to fetch the
    projects list.<br></div></blockquote><div><br></div><div>That sounds like a client-side issue.</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">


    <br>
    <br>
    But this enumeration is going to have to be performed by Horizon
    every time a user initially logs in.</div></blockquote><div><br></div><div>So, an optimization that only benefits a user-initiated operation.</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">In addition, those calls
    would require custom policy on them, and part of the problem we have
    is that the policy needs to exactly match;  if a user can get an
    unscoped token, they need this information to be able to select what
    scope to match for a scoped token.<br></div></blockquote><div><br></div><div>I'm not sure I follow this point - it seems to suggest that unscoped tokens break policy, but the reasoning doesn't seem related?</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"><div class="">
    <br>
    <br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
              <br>
              2.  Unscoped tokens are only initially via HTTPS and
              require client certificate validation or Kerberos
              authentication from Horizon. Unscoped tokens are only
              usable from the same origin as they were originally
              requested.<br>
            </blockquote>
            <div><br>
            </div>
            <div>That's just token binding in use? It sounds reasonable,
              but then seems to break down as soon as you make a call
              across an untrusted boundary from one service to another
              (and some deployments don't consider any two services to
              trust each other). When & where do you expect this to
              be enforced?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    I expect this to be enforced from Keystone.  Specifically, I would
    say that Horizon would get a client certificate to be used whenever
    it was making calls to Keystone on behalf of a user.  The goal is to
    make people comfortable with the endless extension of sessions, by
    showing that it only can be done from a specific endpoint.<br>
    <br>
    Client cert verification can be done in mod_ssl, or mod_nss, or in
    the ssl handling code in eventlet.  <br>
    <br>
    Kerberos would work for this as well, just didn't want to make that
    a hard requirement.<br>
    <br>
    The same mechanism (client cert verification) could be used when
    Horizon talks to any of the other services, but that would be beyond
    the scope of this proposal.</div></blockquote><div><br></div><div>Before we dismiss it as being outside the scope of this proposal, I'd like to understand the intended impact and where the trust boundaries are defined. You didn't seem to answer that here?</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"><div class=""><br>
    <br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
              <br>
              3.  Unscoped tokens should be very short lived:  10
              minutes. Unscoped tokens should be infinitely extensible:
                If I hand an unscoped token to keystone, I get one good
              for another 10 minutes.<br>
            </blockquote>
            <div><br>
            </div>
            <div>Is there no limit to this? With token binding, I don't
              think there needs to be... but I still want to ask.</div>
          </div>
        </div>
      </div>
    </blockquote></div>
    Explicit revoke or 10 minute time out seem to be sufficient. 
    However, if there is a lot of demand, we could make a max token
    refresh counter or time window, say 8 hours.<div class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
              <br>
              4.  Unscoped tokens are only accepted in Keystone.  They
              can only be used to get a scoped token.  Only unscoped
              tokens can be used to get another token.<br>
            </blockquote>
            <div><br>
            </div>
            <div>"Unscoped tokens are only accepted in Keystone": +1,
              and that should be true today. But I'm not sure where
              you're taking the second half of this, as it conflicts
              with the assertion you made in #3: "If I hand an unscoped
              token to keystone, I get one good for another 10 minutes."</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    Good clarification; I wrote  that wrong.  unscoped tokens can only
    be used for <br>
    <br>
    A)  Getting a scoped token<br>
    B)  Getting an unscoped token with an extended lifespan<br>
    C)  (potentially) Keystone specific operations that do not require
    RBAC.<br>
    <br>
    (C) is not in the scope of this discussion and only included for
    completeness.<div class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div>"Only unscoped tokens can be used to get another
              token." This also sounds reasonable, but I recall you
              looking into changing this behavior once, and found a use
              case for re-scoping scoped tokens that we couldn't break?</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br></div>
    It was that use case that triggered this discussion;  Horizon uses
    one scoped token to get another scoped token.  If keystone makes the
    above mechanism the default, then Django-openstack-auth can adjust
    to work with the unscoped->scoped only rule.</div></blockquote><div><br></div><div>It sounds like the only blocker in this thread is a client-side issue that can be resolved in Horizon, and the use case you're describing in horizon is entirely possible without any modifications to Keystone.</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"><div class=""><br>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
              <br>
              Comments?<br>
              <br>
              _______________________________________________<br>
              OpenStack-dev mailing list<br>
              <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
              <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><br>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</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>
    <br>
  </div></div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<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><br>
<br></blockquote></div><br></div></div>