tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Jung <>
Subject Re: Do any of the Tomcat LDAP-type realms support "no password" authentication?
Date Mon, 05 Dec 2011 09:05:37 GMT
On 02.12.2011 17:49, André Warnier wrote:
> wrote:
>> ---- wrote:
>>> ---- "André Warnier" <> wrote:
>>>> wrote:
>>>> ...
>>>>> <Connector port="8009" protocol="AJP/1.3" redirectPort="8443"
>>>>> 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
>>> <Location /samplesajp>
>>> RequestHeader set "REMOTE_USER" "222222229test111111111111"
>>> ProxyPass ajp://
>>> ProxyPassReverse ajp://
>>> </Location>
>>> 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
>> 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 :
> 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 :
> 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

8) The user can be logged in the Tomcat AccessLog using %u.

9) The user is returned by request.getRemoteUser() on the Tomcat side.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message