[openstack-dev] [Keystone][Horizon] Proposed Changed for Unscoped tokens.

Adam Young ayoung at redhat.com
Mon Jul 7 20:05:25 UTC 2014


On 07/07/2014 11:11 AM, Dolph Mathews wrote:
>
> On Fri, Jul 4, 2014 at 5:13 PM, Adam Young <ayoung at redhat.com 
> <mailto:ayoung at 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 at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140707/a27bfe14/attachment.html>


More information about the OpenStack-dev mailing list