<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div><font class="Apple-style-span" face="Courier" size="3"><span class="Apple-style-span" style="font-size: 12px;">
<div>I propose identifying tokens by their full keystone URI within X-Auth-Token header. EG: instead of</div>
<div> X-Auth-Token: fa8426a0-8eaf-4d22-8e13-7c1b16a9370c</div>
<div>we would do</div>
<div> X-Auth-Token: https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>For example, consider rackspace. We might have 3 keystone servers:</div>
<div> region1.customer.keystone</div>
<div> region2.customer.keystone</div>
<div> employee.keystone</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>This creates three ways to do remote federation. </div>
<div> 1) Each service could simply add remote keystone APIs to its whitelists. </div>
<div> 2) A whitelisted keystone server return REDIRECT, which services implicitly trust </div>
<div> 3) A whitelisted keystone server could forward the request directly</div>
<div><br>
</div>
<div>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</div>
<div> <a href="https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c">
https://keystone.utexas.edu/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c</a> </div>
<div>then it mutate the token to hit a trusted keystone implementation:</div>
<div> https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@keystone.utexas.edu </div>
<div><br>
</div>
<div>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.</div>
</span></font></div>
<font face="monospace">This email may include confidential information. If you received it in error, please delete it.</font></body>
</html>