Difference between revisions of "Keystone-Essex-Federated-Token"

Revision as of 15:31, 12 September 2011

Full conversation:

There's been a lot of interest in a finer-grained Vary function (i.e., something that lets you specify the cache key on something more flexible than just whole headers). We're working a a spec in the background, but of course caches will need to support it...

Cheers,

On 05/09/2011, at 3:43 PM, Bryan Taylor wrote:

It _would_ be useful to have Vary pick out a link by its rel, even on a request. Maybe the rel="" part should've been considered part of the  header: Link;rel="Keystone-token" : blah

Or maybe Vary should support matching on header values:

Vary: Link:*;rel="keystone-token"

On 9/4/11 9:51 PM, "Mark Nottingham" < mnot@mnot.net > wrote:

Good point; Link makes more sense on a response.

Cheers,

On 05/09/2011, at 12:49 PM, Bryan Taylor wrote:

Hmmm, I'm thinking more about this. Would using the Link: header break the ability to use the Vary header? I can't Vary on a Link header based on it's rel attribute.

So maybe Keystone-Token is the way to go. I could see intermediaries doing the token resolution and adding headers like Keystone-User and Keystone-Tenant which could also be used in Vary Headers.

On 9/4/11 8:06 PM, "Bryan Taylor" < btaylor@rackspace.com > wrote:

Love it.

Link:

<https://keystone.server/tokens/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c>; rel="keystone-token"

Fixed: s/tenants/tokens/ (my bad).

On 9/4/11 7:40 PM, "Mark Nottingham" < mnot@mnot.net > wrote:

Still getting up to speed on the finer points of keystone, but makes sense to me.

Is X-Auth-Token keystone-specific? If so, calling it something like "Keystone-Token" would be better (X- is falling out of favour; see

<http://tools.ietf.org/html/draft-saintandre-xdash-03>). That'd also avoid problems with people expecting the other format. Finally, if you're going to make it a URI, best to enclose it in quotes - URIs can contain commas, which can be a delimiter in HTTP headers (especially if multiple tokens might be allowed).

E.g.,

Keystone-Token: "https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c"

Cheers,

P.S. If these are going to show up in other contexts, it *might* make sense to define keystone-token as a link relation <http://tools.ietf.org/html/rfc5988>, giving you:

Link:

<https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c>; rel="keystone-token"

On 04/09/2011, at 2:39 AM, Bryan Taylor wrote:

I propose identifying tokens by their full keystone URI within

X-Auth-Token header. EG: instead of

  X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c

we would do:

  X-Auth-Token: https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c

This has the advantage of allowing federated tokens, and allowing APIs and even resources to use the auth server in access decisions. A given service would maintain a whitelists of keystone servers. The service would take the request, get the token, and verify that the host of the token URI matches one from the appropriate whitelist, and then do a GET on the token per the keystone API.

For example, consider rackspace. We might have 3 keystone servers:

region1.customer.keystone

region2.customer.keystone

employee.keystone

The management API might set it's whitelist to {employee.keystone}, while the public APIs could whitelist all three, or maybe just the first two.

This creates three ways to do remote federation:

1) Each service could simply add remote keystone APIs to its whitelists.

2) A whitelisted keystone server return REDIRECT, which services implicitly trust

3) A whitelisted keystone server could forward the request directly

Items 2 and 3 might be facilitated by adding an "@host" string to the end of the token to allow the keystone implementation to map the token to its source. Eg: if the service receives a token that is not from a whitelisted client, such as

https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c

then it mutate the token to hit a trusted keystone implementation:

https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@keystone.utexas.edu

The keystone.server implementation could verify the trust relationship with keystone.utexas.edu and redirect or forward back to the original.

This would allow remote federations to be controlled by the trusted keystone servers in a way that a client can leverage with no special knowledge ­ they just auth against their normal keystone servers and proceed.