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

2011-09-12 Thread Joe Savak 
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@lists.launchpad.net 
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On 
Behalf Of Mark Nottingham
Sent: Wednesday, September 07, 2011 2:11 AM
To: Bryan Taylor
Cc: openstack@lists.launchpad.net
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"  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"  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"  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
>>>>>

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

2011-09-07 Thread Mark Nottingham 

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"  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"  wrote:
>>> 
 Love it. 
 
 
 Link: 
 ;
 rel="keystone-token"
 
 
 Fixed: s/tenants/tokens/ (my bad).
 
 
 On 9/4/11 7:40 PM, "Mark Nottingham"  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
> ). 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
> , giving you:
> 
> Link: 
> 
> ;
> 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

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

2011-09-04 Thread Bryan Taylor 
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"  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"  wrote:
>> 
>>> Love it. 
>>> 
>>> 
>>> Link: 
>>> ;
>>> rel="keystone-token"
>>> 
>>> 
>>> Fixed: s/tenants/tokens/ (my bad).
>>> 
>>> 
>>> On 9/4/11 7:40 PM, "Mark Nottingham"  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
 ). 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
 , giving you:
 
 Link: 
 
;
 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.l

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

2011-09-04 Thread Mark Nottingham 
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"  wrote:
> 
>> Love it. 
>> 
>> 
>> Link: 
>> ;
>> rel="keystone-token"
>> 
>> 
>> Fixed: s/tenants/tokens/ (my bad).
>> 
>> 
>> On 9/4/11 7:40 PM, "Mark Nottingham"  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
>>> ). 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
>>> , giving you:
>>> 
>>> Link: 
>>> ;
>>> 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 re

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

2011-09-04 Thread Bryan Taylor 
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"  wrote:

>Love it. 
>
>
>Link: 
>;
>rel="keystone-token"
>
>
>Fixed: s/tenants/tokens/ (my bad).
>
>
>On 9/4/11 7:40 PM, "Mark Nottingham"  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
>>). 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
>>, giving you:
>>
>>  Link: 
>>;
>>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.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

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

2011-09-04 Thread Bryan Taylor 
Love it. 


Link: 
;
rel="keystone-token"


Fixed: s/tenants/tokens/ (my bad).


On 9/4/11 7:40 PM, "Mark Nottingham"  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
>). 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
>, giving you:
>
>  Link: 
>;
>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@keys
>>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

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

2011-09-04 Thread Mark Nottingham 
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 
). 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 , 
giving you:

  Link: ; 
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-7c1b16a93...@keystone.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/




___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

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

2011-09-03 Thread Bryan Taylor 
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-7c1b16a93...@keystone.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