Cédric Couralet wrote:
2014-02-11 10:41 GMT+01:00 André Warnier <a...@ice-sa.com>:
Cédric Couralet wrote:
2014-02-11 1:20 GMT+01:00 Elliot Kendall <elliot.kend...@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.
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 :
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPJavaInstall
"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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
