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" <btay...@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" <m...@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@key >>>> s >>>> tone.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@lists.launchpad.net >>>> Unsubscribe : https://launchpad.net/~openstack >>>> More help : https://help.launchpad.net/ListHelp >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >>> >> >> This email may include confidential information. If you received it in >> error, please delete it. >> >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp > > This email may include confidential information. If you received it in error, > please delete it. -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
