Apache mod_proxy, Jetty, and IDP endopint problem

[Wessel, Keith]

I lik this. Nice and simple.

But the original question of an existing REMOTE_USER header faked by a client still stands. However, I'm guessing that, if the REMOTE_USER env var is unset, that RequestHeader directive would, in fact, blank out any existing REMOTE_USER header var. Is that a true assumption? Do we know?

Keith


-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Jim Fox
Sent: Thursday, June 11, 2015 3:10 PM
To: Shib Users
Subject: Re: Apache mod_proxy, Jetty, and IDP endopint problem


Some good points in the article.  You warning about the rewrite condition 
led me to realize it is not needed.  Since I know by configuration that 
remote_user is set all I need is

   RequestHeader set REMOTE-USER %{REMOTE_USER}s

My concern was making sure a client-supplied remote-user header wouldn't overrule mine. 
It seems that as long as all parties treat headers insensitive to case, which mod_headers and 
j2ee's getHeader both do, my setting will always overwrite anything passed in on 
the request--regardless of how that one is cased.

Jim

>> 
>> To get a REMOTE_USER to the Idp:
>>
>>   RewriteEngine On
>>   RewriteCond %{LA-U:REMOTE_USER} (.+)
>>   RewriteRule . - [E=RU:%1]
>>   RequestHeader set REMOTE-USER %{REMOTE_USER}s
>> 
>> and then configure the idp to get remoteuser from the header.
>
> Just a heads up, having dealt extensively with proxying from Apache to a J2EE 
> servlet I can tell you the above only works with 1 environment variable. If 
> you google the above will always turn up as the recommended solution. If you 
> try to send more than one environment variable the LA-U RewriteCond logic 
> seems to get into an infinite loop (or infinite recursion).  I never was able 
> to figure out how to send more than one environment variable despite pouring 
> over the Apache source code and many hours spent in the debugger tracing 
> things. It was pretty opaque.
>
> I authored the following document for another project, it has nothing to do 
> with SAML, but nonetheless it describes a configuration where Apache is used 
> as a front end performing authentication and identity lookup's and then 
> passing (e.g. proxying) to a J2EE servlet running in either Jetty or Tomcat. 
> Although a large part of the document discusses issue specific to the project 
> there are a number of sections dealing with the proxy problem and it's 
> security, those you may find interesting.
>
> https://jdennis.fedorapeople.org/doc/sssd_configuration.pdf
>
> Ultimately what we did when we couldn't use AJP was add a servlet filter that 
> extends HttpServletRequestWrapper and overrides the methods getRemoteUser(), 
> getAuthType(), getAttribute() etc. and pulls the data out of the request 
> header if it not already set. The advantage of this approach is that existing 
> servlet code does not need to be modified, it remains completely ignorant of 
> the underlying transport, in other words you get the advantages of AJP 
> without having to use AJP.
>
> I'm happy to share the filter code if there is an interest.
>
> John
> -- 
> To unsubscribe from this list send an email to 
> users-unsubscribe at shibboleth.net
>
-- 
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net