tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Couralet <>
Subject Re: AJP and attributes versus headers
Date Tue, 11 Feb 2014 10:03:26 GMT
2014-02-11 10:41 GMT+01:00 André Warnier <>:

> Cédric Couralet wrote:
>> 2014-02-11 1:20 GMT+01:00 Elliot Kendall <>:
>>  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.
Yes, I did not mean REMOTE_USER as header but as the environment variable
in apache httpd (I don't know how to call it). I picked it up from this
page  :

"Setting the tomcatAuthentication="false" attribute on the AJP
<Connector>element allows for passing
REMOTE_USER from Apache httpd. See Tomcat's AJP Connector documentation for

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message