Open Stack

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110903/6b7c7b10/attachment.html>