<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/07/2014 11:11 AM, Dolph Mathews
wrote:<br>
</div>
<blockquote
cite="mid:CAC=h7gX_GFcQw1AZY_RFn077QWJUY6RzLeSFSwgB2x4N1P4Lug@mail.gmail.com"
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 moz-do-not-send="true"
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>
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>
<br>
<br>
But this enumeration is going to have to be performed by Horizon
every time a user initially logs in. 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>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gX_GFcQw1AZY_RFn077QWJUY6RzLeSFSwgB2x4N1P4Lug@mail.gmail.com"
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>
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.<br>
<br>
<br>
<blockquote
cite="mid:CAC=h7gX_GFcQw1AZY_RFn077QWJUY6RzLeSFSwgB2x4N1P4Lug@mail.gmail.com"
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>
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.<br>
<br>
<blockquote
cite="mid:CAC=h7gX_GFcQw1AZY_RFn077QWJUY6RzLeSFSwgB2x4N1P4Lug@mail.gmail.com"
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>
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.<br>
<br>
<blockquote
cite="mid:CAC=h7gX_GFcQw1AZY_RFn077QWJUY6RzLeSFSwgB2x4N1P4Lug@mail.gmail.com"
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>
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.<br>
<br>
<blockquote
cite="mid:CAC=h7gX_GFcQw1AZY_RFn077QWJUY6RzLeSFSwgB2x4N1P4Lug@mail.gmail.com"
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 moz-do-not-send="true"
href="mailto:OpenStack-dev@lists.openstack.org"
target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a moz-do-not-send="true"
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 class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</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>