On 07/07/2014 11:11 AM, Dolph Mathews wrote:
On Fri, Jul 4, 2014 at 5:13 PM, Adam Young <ayo...@redhat.com
<mailto:ayo...@redhat.com>> wrote:
Unscoped tokens are really a proxy for the Horizon session, so
lets treat them that way.
1. When a user authenticates unscoped, they should get back a
list of their projects:
some thing along the lines of:
domains [{ name = d1,
projects [ p1, p2, p3]},
{ name = d2,
projects [ p4, p5, p6]}]
Not the service catalog. These are not in the token, only in the
response body.
Users can scope to either domains or projects, and we have two core
calls to enumerate the available scopes:
GET /v3/users/{user_id}/projects
GET /v3/users/{user_id}/domains
There's also `/v3/role_assignments` and `/v3/OS-FEDERATION/projects`,
but let's ignore those for the moment.
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?
It is a little more than just an optimization.
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.
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.
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.
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?
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.
Client cert verification can be done in mod_ssl, or mod_nss, or in the
ssl handling code in eventlet.
Kerberos would work for this as well, just didn't want to make that a
hard requirement.
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.
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.
Is there no limit to this? With token binding, I don't think there
needs to be... but I still want to ask.
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.
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.
"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."
Good clarification; I wrote that wrong. unscoped tokens can only be
used for
A) Getting a scoped token
B) Getting an unscoped token with an extended lifespan
C) (potentially) Keystone specific operations that do not require RBAC.
(C) is not in the scope of this discussion and only included for
completeness.
"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?
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.
Comments?
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
