openstack team mailing list archive

[Joe Savak <joe.savak@xxxxxxxxxxxxx>]

Mark & Bryan,
	I haven't forgotten about this and included it on the keystone wiki so we won't lose track of it during Essex planning.
http://wiki.openstack.org/keystone

Thanks,
Joe

-----Original Message-----
From: openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Mark Nottingham
Sent: Wednesday, September 07, 2011 2:11 AM
To: Bryan Taylor
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Proposal: URIs for X-Auth-Header Keystone tokens


There's been a lot of interest in a finer-grained Vary function (i.e., something that lets you specify the cache key on something more flexible than just whole headers). We're working a a spec in the background, but of course caches will need to support it...

Cheers,



On 05/09/2011, at 3:43 PM, Bryan Taylor wrote:

> 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@xxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
>>>>>> 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@xxxxxxxxxxxxxxxxxxx
>>>> 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.
> 

--
Mark Nottingham   http://www.mnot.net/




_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
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.