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" <m...@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" <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-7c1b16a937 >>>>>0c >>>>> >>>>> then it mutate the token to hit a trusted keystone implementation: >>>>> >>>>> >>>>>https://keystone.server/tenants/fa8426a0-8eaf-4d22-8e13-7c1b16a9370c@k >>>>>ey >>>>> 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/ > > > 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