tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: AJP and attributes versus headers
Date Tue, 11 Feb 2014 12:33:02 GMT
Cédric Couralet wrote:
> 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).

Yes, that terminology is somewhat confused and confusing.
I call them "Apache httpd variables", because they are not like environment variables for

the Apache httpd process itself, nor like environment variables for the cgi-bin processes

that Apache httpd starts (SetEnv), nor like mod_perl variables (PerlSetEnv), nor are they

http headers.
And in Tomcat/AJP parlance, the closest things are called "request attributes", but which

at the Apache httpd level with mod_jk, one sets with the "JkEnvVar" directive; and with 
the mod_proxy module one sometimes sets them via "Parameters" or "Options".
Which are of course not the same at all as the attributes of a Tomcat Connector tag...

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message