Open Stack

On 11/15/2012 11:59 AM, Kevin L. Mitchell wrote:
> On Thu, 2012-11-15 at 09:56 -0500, Adam Young wrote:
>> OK, if I understand correctly, there are two distinct issues getting
>> mixed here.
>>
>> 1.  Handling tokens in HTTP environments.
>> 2.  Extending the data that is carried in the Auth token signed document.
>>
>> My gut feeling is that additional Headers is a mistake.  The payload of
>> the signed messages should be extracted only once, expanded, and added
>> to the WSGI context.  Anything that needs to consume the data downstream
>> should read it as Python objects, not as strings out of headers.  I
>> never really understood the rationale for additional custom headers from
>> validate.
> The reason I chose the headers route, rather than the wsgi environment
> route, was because of an original design goal of the auth_token
> middleware.  In retrospect, it's not necessary for my change to have
> been done the way I did, and placing the extracted token validation into
> the wsgi environment makes sense.  However, in answer to your statement,
> about custom headers, maybe it'd be worth mentioning the design goal, as
> I understand it, of how auth_token was designed.
>
> In short, the auth_token middleware was designed so that it could be run
> from a proxy, rather than directly in the WSGI pipeline.  The idea was
> to allow for a case where you have a reverse proxy, which performs the
> authentication check, then forwards the HTTP request (with the added
> authentication headers) on to the actual service running on another host
> entirely.  In addition, using the headers allows for alternate
> authentication implementations; as long as they set the same headers,
> you can use any authentication backend you want.
I think it complicates things.  I'd rather use the auth token headers we 
have, or focus on heading back toward standard headers.

However, you do bring up an interesting use case: offloading the token 
validation does make sense in some setups, and I am not sure how we 
would want to tie in with the WSGI spec in those cases.  My suspicion is 
that there is a better way than customer headers.  If, for example, 
someone had already done the LDAP lookup for groups (AuthZ) in a 
Kerberos (AuthN) implementation,  that information gets filtered at the 
Proxy. I don't know of a standard way of passing that information on the 
the WSGI App.  Have you done the research to show that there is not good 
way to do this?