Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.229 as permitted sender)
Message-ID: <52F9F02C.5040708@ice-sa.com>
Date: Tue, 11 Feb 2014 10:41:00 +0100
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: AJP and attributes versus headers
References: <20140211002056.GD31484@dx4.org>
 <CAMwoAzfL3fG6DUsw1xATFVoHeE1v67M8gZgwS0rDo04SP5nLyw@mail.gmail.com>
In-Reply-To: 
 <CAMwoAzfL3fG6DUsw1xATFVoHeE1v67M8gZgwS0rDo04SP5nLyw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

C�dric Couralet wrote:
> 2014-02-11 1:20 GMT+01:00 Elliot Kendall <elliot.kendall@ucsf.edu>:
> 
>> We have a Java application running on Tomcat with an Apache HTTP proxy
>> in front. Our SSO system (Shibboleth) runs as an Apache module and sets
>> an HTTP header with the logged-in username, which gets passed through
>> to Tomcat and which the app uses Spring's
>> RequestHeaderAuthenticationFilter to read.
>>
>> We would like to switch from HTTP to AJP for the proxy, as recommended
>> by our SSO vendor. When we do, though, the logged-in username ends up
>> in an environment variable and gets passed to Tomcat as a request
>> attribute rather than a header. The Spring filter is using
>> javax.servlet.http.HttpServletRequest.getHeader to read the value,
>> which fails. For things to work, it would need to use
>> javax.servlet.ServletRequest.getAttribute. As far as I can tell, no
>> filter exists in Spring that uses requests instead of headers.
>>
>> Is there a way to make Tomcat expose the values of AJP request
>> attributes as headers so that the Spring filter can see them? Or maybe
>> a way to make one the user principal, accessible through
>> javax.servlet.http.HttpServletRequest.getUserPrincipal? Then I could
>> use a different Spring filter, J2eePreAuthenticatedProcessingFilter).
>> And if there is a way to do one or both of these, do you think I would
>> be better off trying to fix this on the Spring side?
>>
>>
> You could try setting tomcatAuthentification="false" on your AJP connector
> in server.xml. If Shibboleth put the value in REMOTE_USER as it should then
> tomcat should pick it up as the principal.
> Be aware that you should protect your ajp connector so that no other
> machine than your Apache can connect to it.
> 

Cedric,
I think that the essence of the above is correct, but that strictly speaking the details 
are not.
I do not think that the authenticated user-id from Apache is passed via (or taken from) 
the REMOTE_USER header.  The mod_jk and mod_proxy_ajp modules most probably take the 
Apache authenticated user-id directly from the Apache "request record" (r->user), no 
matter how it has been set, and pass it on to Tomcat throughj AJP as a request attribute.
The setting of the REMOTE_USER http header is just a side-effect, and may be happening or not.
The AJP connector at the Tomcat level, if tomcatAuthentication="false", then uses the 
value of the received AJP request attribute to set Tomcat's request userPrincipal value.
There is no need then for anything else in Tomcat to grab the REMOTE_USER header of the 
request.

I do not know Shibboleth, but I would presume that when it authenticates a user, it sets 
the Apache r->user first. And then maybe, accessorily and/or optionally, Shibbolet may add 
a REMOTE_USER header to the request.

And at the Tomcat level, one /may/ have some authentication module that picks up the 
user-id from the REMOTE_USER header of the request, and sets it as the Tomcat userPrincipal.

But what I mean to say is that both these things with the REMOTE_USER http header are not 
mandatory.  If Apache httpd authenticates a user, by whatever well-written method, the 
httpd r->user will be set, and the proxied AJP request will contain the corresponding 
user-id.  And if the Tomcat AJP <Connector> says tomcatAuthentication="false", then the 
Connector will pick up this user-id from the AJP request attribute, and set the Tomcat 
user to that value.  Independently of any REMOTE_USER header being set or not.

Of course you can always override this, and force the usage of the REMOTE_USER header on 
both sides. But why would you do that, if a standard mechanism is already built-in into AJP ?
(It would be different if you were using mod_proxy_http as a connector).

> 
> 
> 
>> Thanks for any suggestions.
>>
>> --
>> Elliot Kendall
>> IAM Support Engineer - Single Sign On
>> Information Technology Services
>> University of California, San Francisco
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org