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.
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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
