Hello Matt, I think the RemoteIpValve does what you need : it looks at http headers filled in the request by preceding network components (layer 7 load balancer, ssl accelerator, etc) such as 'x-forwarded-for' to get the real ip address and 'x-forwarded-proto' to get the http/https protocol. A concept of internal/trusted incoming proxies is used to decide weither the http headers can be trusted or not.
Configuration is detailed in the javadocs : http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html The documentation of RemoteIpValve has been enhanced in Tomcat 7 to integrate the content of the java doc. I wrote a blog post in french to explain how it works with detailed diagrams here : http://blog.xebia.fr/2009/11/13/tomcat-ssl-communications-securisees-et-x-forwarded-proto/ Basically, if you want to trust http header x-forwarded-for and x-forwarded-proto coming from LB/web-server 192.168.0.10 and 192.168.0.11, the valve configuration will look like : <Server ...> ... <Service name="Catalina"> <Connector ... /> <Engine ...> <!-- Process X-Forwarded-For to get remote address and X-Forwarded-Proto to identify SSL requests --> <Valve className="org.apache.catalina.valves.RemoteIpValve" internalProxies="192\.168\.0\.10, 192\.168\.0\.11" protocolHeader="X-Forwarded-Proto" /> <!-- AccessLogValve must be declared after RemoteIpValve to get the remote address and the scheme https/http --> <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="common" prefix="access_log." resolveHosts="false" suffix=".txt" /> ... </Host> </Engine> </Service> </Server> Please note that you can simplify the configuration omitting 'internalProxies' attribute and rely on the default that trusts all the class A, B & C private IP addresses. Hope this helps, Cyrille -- Cyrille Le Clerc clecl...@xebia.fr http://blog.xebia.fr On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson <matt.peter...@une.edu.au> wrote: > > Hi All, > > > > We have a hardware load balancer terminating SSL requests before making a > plain-text connection with Tomcat. So that all contexts are aware that the > request is actually a secure request, we have implemented the RemoteIpValve > with a LB injected header. This works well for our apps. However, we have > noticed that there is some processing of the request happening within the > connector, before the valves are processed. In particular, the redirecting > to URLs with a trailing slash. Because this processing is occurring before > the valves are processed the Connector still thinks that the original > request was a non-secure one, even though it was not. The result is that > requests to https://domain.name/context are redirected to > http://domain.name/context/ instead of to https://domain.name/context/. This > is not major, because our LB then redirects from http://domain.name/context/ > to https://domain.name/context/ and all is good (except for the extra > redirect). > > > > I can't find any documentation on the order of events for the Connector, so > I'm not sure what other decisions get made based on the request attributes, > but assume there are others. > > > > Is there another solution to handling proxied SSL requests so that Catalina > as well as our apps are aware that the requests are secure??? One > possibility is to have two Connectors (1 using the secure, scheme and > serverPort attributes for secure and 1 for non-secure) and have the LB > connect to the appropriate Connector depending on the request. But this > effectively doubles the amount of config needed to be managed (2nd set of > config for LB + 2nd connector), which is considerable when dealing with 6 TC > clusters each with their own set of LB config. > > > > Should I lodge an enhancement request for the Connector to become aware of > proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala > WebLogic)? > > > > Cheers, > > Matt. > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
