Hello, > Anything in particular? Plumbing code is always not terribly pretty. > > It's kept up-to-date and generally supports more features than > mod_proxy_ajp.
Well, there was a point where 64bit windows builds didn't even work - which tells me there's not a lot of testing going on. And having got involved and contributed a few years ago, I recall the code being somewhat in need of refurbishment, as does pretty much all 15+ year old C/Java/.... > > I see your point regarding the ajp protocol but equally, HTTP is > > everywhere and if every other part of a web stack is HTTP, there > > seems little value in doing anything different between Apache & > > Tomcat. > > There are some slight optimizations in comparison to AJP. When HTTPS/2 > (which is very much like AJP) hits, you'll see less of a difference. I don't think there's any good reason to use AJP over HTTP with respect to web performance. Pretty much any bottleneck exists in the application, or the plethora of components it uses, not the transport layer. AJP is merely obscuring a request that in many (commercially deployed) solutions originated from a device with a number of other solutions in-between it and Apache/IIS, ie the F5, an Akami layer, BlueCothe protocol that one can't get away from; that everyone understands and can easily debug with telnet/etc)at, etc. > > AJP has various load balancing features/etc and if that's what one > > wants, fine, but most organisations have hardware load balancers > > etc to do this for them now-a-days. > > Also, mod_proxy_* does load-balancing. This is not a feature of the > protocol, but of the tool. Yes, I appreciate that, but mod_proxy/mod_jk LB is not used in your day to day commercial solution that - rightly or wrongly - consider Apache/Tomcat as one (often, people don't even know the difference!) and do the load balancing in the corporate wide solution. > > Going back to my request, I note the Servlet Specification API > > docs state that getRemoteUser should return the CGI variable > > REMOTE_USER: > > > > http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/http/ > HttpServletRequest.html#getRemoteUser() > > > > But as I've highlighted, it does not, so Tomcat is in breach of > > the spec. How can this be raised as a bug? > > REMOTE_USER is not an HTTP header... it's the "REMOTE_USER" CGI > variable Yet they are used interchangeably. And we're not discussing mod_[fast]cgi, but a completely different architecture/solution. > So, your proposed implementation is incorrect and represents > a security vulnerability. It does not represent a security vulnerability. Any application that trusts a user via REMOTE_USER, whether via the HTTP or AJP connector is doing so knowingly. And in such a case, a pen-test would fail unless there were extra measures in place (Tomcat's AJP or HTTP connector listening on localhost; restricted access to the host), but they are no substitute for authenticating within Tomcat. Apache authenticating on behalf of Tomcat is a bad decision, but a decision still forced upon some because of vendors not providing Java authentication solutions out of the box (ie CA SiteMinder, RSA Access Manger, Tivoli, etc). If the vendor pushes and only actively supports an Apache front end, one has to use an Apache front end. Setting up mod_proxy_http is easier than mod_[proxy_]jk. Everyone understands HTTP, and I'd like Tomcat to more easily integrate with Apache (and the various authentication modules) using HTTP. > Tomcat is compliant insofar as there is no standard that covers where > the REMOTE_USER CGI variable should be set or what its value should > be. When a user is logged-into a web application, > request.getRemoteUser returns the name of the currently-logged-in > user. When no user is logged-in, it returns null. That seems to be > compliant to me. Well, admitting there's no standard and then stating is compliant is an interesting conclusion :) > How do you want it to behave instead? It should be consistent with the AJP Interface. Either they both return a user on getRemoteUser() or they don't. The tomcatAuthentication flag on the AJP connector tells Tomcat to trust the REMOTE_USER header/CGI variable/whatever we wish to call it. With a simple change to the HTTP connector, it can do the same. Rename REMOTE_USER to X_UNTRUSTED_USER if you wish, but this no more or no less secure than the AJP connector because one has to 'opt in' to the security issue. I would also like to see Tomcat reporting the obvious security hole when this approach is used (for either AJP or HTTP) by reporting to the logs if the connector is not bound to localhost/etc. I'm amazed at how often I find Apache+Tomcat deployed with zero security on the AJP connector and no-one appearing to understand the issue. > If you want to have the web server report the REMOTE_USER CGI variable > to Tomcat, you'll have to arrange that for yourself. And indeed it's not hard to do so, but if one wants to get rid of AJP and stick with pure HTTP, then a Tomcat Valve is required to set the Principal when REMOTE_USER is passed as an HTTP header from Apache. It's an extra level of effort that people can do without. So in summary: * There's no security issue with my proposal above and beyond what is already considered an issue with AJP. * Tomcat should provide much more informative reporting when security issues are opened up through the use of AJP and tomcatAuthentication="false". * If we really don't like the idea of getRemoteUser() returning REMOTE_USER (set as an HTTP Header or provided by mod_jk) then maybe a Valve can be included by default that wraps up both the logging and functionality (I'm happy to write it). John John --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
