openstack team mailing list archive

[Bryan Taylor <btaylor@xxxxxxxxxxxxx>]

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-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@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.