[Openstack] Proposal: URIs for X-Auth-Header Keystone tokens

Bryan Taylor btaylor at rackspace.com
Mon Sep 5 05:43:43 UTC 2011


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" <mnot at 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" <btaylor at 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" <mnot at 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 at 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 at 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.





More information about the Openstack mailing list