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

Mark Nottingham mnot at mnot.net
Mon Sep 5 02:51:41 UTC 2011


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-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 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/







More information about the Openstack mailing list