Open Stack

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.