Open Stack

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.
> This email may include confidential information. If you received it in error, please delete it.
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

--
Mark Nottingham   http://www.mnot.net/