On 02.12.2011 17:49, André Warnier wrote: > ohaya@cox.net wrote: >> ---- ohaya@cox.net wrote: >>> ---- "André Warnier" wrote: >>>> ohaya@cox.net wrote: >>>> ... >>>>> >>>> tomcatAuthentication="false" /> >>>>> >>>> That is correct. The "false" means that Tomcat will not do it's own >>>> authentication, and will instead rely on the authenticated user-id >>>> passed by the front-end server. >>>> >>>> Now could you also show us the section of your Apache front-end >>>> configuration, containing the directives which forward the requests >>>> to Tomcat ? >>>> (proxy or rewrite stanzas) >>>> >>>> Note: the fact that the Apache/Tomcat connector (the one at the >>>> Apache level) passes the authenticated user-id to Tomcat along with >>>> the proxied request, depends on the fact that within Apache (more >>>> precisely within the internal Apache "request record"), the request >>>> is really authenticated (*). >>>> I am saying this because in an earlier post, you mentioned that you >>>> were using a third-party authentication package at the Apache httpd >>>> level. >>>> It is unlikely, but possible, that this authentication package would >>>> use its own logic, and never "populate" the internal Apache request >>>> record with this user-id (**). >>>> In such a case, the automatic forwarding of the user-id by the >>>> Apache-level connector module (mod_proxy_ajp or mod_jk) would of >>>> course not work, because they check the internal Apache request >>>> record, and have no knowledge of another user-id source. >>>> >>>> >>>> (*) in Tomcat terms, the equivalent of populating the userPrincipal >>>> object >>>> (**) for example, it may act as a filter, and rely on each request >>>> always containing a cookie which "authenticates" the request, and do >>>> its own access control independently of Apache httpd itself >>>> >>> >>> Andre, >>> >>> Sure. Here's the section from httpd.conf. This is testing where I >>> purposely insert a "REMOTE_USER" HTTP header into the request being >>> proxied. As I said, I have a sniffer on the line, and I can see the >>> REMOTE_USER header, but still, when I get to my test JSP hosted on >>> the Tomcat, getUserPrincipal() is returning null (don't mind the >>> hostname in the ProxyPass, etc. I just happen to be hosting Tomcat on >>> that machine, and WebLogic is shutdown there). >>> >>> >>> # Proxy to Tomcat on weblogic1 machine, using AJP >>> >>> RequestHeader set "REMOTE_USER" "222222229test111111111111" >>> ProxyPass ajp://weblogic1.whatever.com:8009/samplesajp >>> ProxyPassReverse ajp://weblogic1.whatever.com:8009/samplesajp >>> >>> >>> Jim >>> >>> >> >> Hi, >> >> BTW, I asked about this earlier, but is it possible to turn on some >> debugging on the Tomcat side, that might help diagnose why the AJP >> connector is not working the expected way? I'm not that familiar with >> Tomcat or AJP logging, but I've only been able to set logging in >> logging.properties so that there's either almost no logging or it >> generated a ton of logging (but not stuff on AJP >> connection/processing) :(... >> > Sorry, dunno. Logging is not my favorite area in Tomcat.. > > Also, to tell the truth, I do not know exactly /how/ the Apache user-id > is passed to Tomcat. I strongly suspect that the "REMOTE_USER" HTTP > header may not be it, and that it may be via what Tomcat calls "request > attributes", and Apache calls "environment variables" (but not in the > usual shell sense). But I don't know how this particular one may be named. > Since you seem better at Java that I am, you may be able to find it in > the Tomcat AJP Connector code somewhere. I would start looking for > "request attribute" rather than "header". > > This page : http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html > seems to hint at ditto, and even mentions a request attribute named > "remote_user" (lowercase). > > Maybe you could try to set this "environment variable" in Apache, and > see where it leads you ? > In this page : > http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html#rewriterule > it shows how to do that (but there it calls them "server variables"). > The terminology is not very consistent.. Although this thread has moved forward towards the role topic, I want to give some infos about the user forwarding by mod_jk. Some of it was already present in previous posts. 1) In order to let Tomcat accept the user, you need to set tomcatAuthentication to "false" 2) mod_jk will always forward the user as detected by the following logic: - the user as authenticated by Apache - if this doesn't exist it will forward the value of an Apache environment variable. The default name of the variable is "JK_REMOTE_USER", but it can be changed using the configuration directive "JkRemoteUserIndicator" 3) The user ID will *not* be forwarded in the form of a request header 4) The forwarded user id is logged in the JK log file on level debug as the "user" field in the line: Service protocol=%s method=%s ssl=%s host=%s addr=%s name=%s port=%d auth=%s user=%s laddr=%s raddr=%s uri=%s 5) There is no need to use JkEnvVar 6) When not using a real Apache authentication, you can instead set the Apache environment variable JK_REMOTE_USER e.g. via mod_setenvif or the E= syntax of mod_rewrite. If you change the name of the env var using JkRemoteUserIndicator use the variable name given there instead. 7) The Apache authenticated user can be logged in the Apache AccessLog using "%u". Any environment variable XXX can be logged using %{XXX}e. 8) The user can be logged in the Tomcat AccessLog using %u. 9) The user is returned by request.getRemoteUser() on the Tomcat side. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org