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