<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><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><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><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><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><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>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote></div><br></div></div>