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.




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

Reply via email to