On Fri, Jul 4, 2014 at 5:13 PM, Adam Young <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?
>
>
> 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?
>
>
> 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.
>
>
> 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."
"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?
>
>
> Comments?
>
> _______________________________________________
> 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
