Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4E7738D9.3030007@ice-sa.com>
Date: Mon, 19 Sep 2011 14:43:05 +0200
From: =?ISO-8859-1?Q?Andr=E9_Warnier?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Http connector and remote user information
References: 
 <CA+x0o3kOQu0rqj9Hmo4cbjX=BQWq2fJPSTNNgaxrwxOPWdGRmA@mail.gmail.com>
 <4E731801.8080802@ice-sa.com>
 <CA+x0o3kkaC2TgE-z02mWcQ9RTAe4FPTGtoUUnZQWdnMd8nxh6A@mail.gmail.com>
In-Reply-To: 
 <CA+x0o3kkaC2TgE-z02mWcQ9RTAe4FPTGtoUUnZQWdnMd8nxh6A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi.

I am not knowledgeable enough in Java code to tell if there is something wrong with the 
method, but if it works for you, that's the most important aspect.

By curiosity, how are you telling Apache to add this header ?

And one more thing, which I am sure you must have considered, but maybe worth mentioning 
anyway :

If your Tomcat server is accessible via other channels than from the Apache front-end, 
then this is of course a security hole, since anyone can forge such a HTTP header and send 
it to Tomcat.  So I would only use this in conjunction with a RemoteAddress Valve, or by 
having Tomcat listening only on a IP address which only the Apache host can access.
(Or encrypting/decrypting the header, but that is more of a hassle).

Essentially mod_jk and mod_proxy_ajp have the same issue, but the AJP protocol is a bit 
more difficult to handle and play with, than straight HTTP.


Sylvain Goulmy wrote:
> Thank you Andr� for your contribution which was very helpful.
> 
> If you are using the first one (HTTP), then one way would be to force Apache
>> to add a HTTP header to the request, containing the user-id; and on the
>> Tomcat side, have something that picks up this HTTP header, and stuffs its
>> content in the UserPrincipal object.
>> I don't know if something like that exists ready-made, but a custom Valve
>> or servlet filter should be able to do that.
> 
> 
> This is effectively the solution i had chosen, i should have mentionned it.
> Actually i was looking for the implementation on the tomcat side that's why
> i was looking how the ajp connector was using the user-id data to set the
> remote user. You gave me the solution by mentionning the UserPrincipal
> object as i was on the wrong place looking for a setRemoteUser() method.
> 
> Here is the code of the valve which give me the expected result :
> 
> public class RemoteUserValve extends ValveBase {
>>         public void invoke(Request request, Response response) throws
>> IOException, ServletException {
>>                 String remoteUser = request.getHeader("X-Forwarded-User");
>>                 Principal userPrincipal = request.getPrincipal();
>>                 if (userPrincipal != null) {
>>                         System.out.println("Principal getName : " +
>> userPrincipal.getName() + ".");
>>                         System.out.println("Principal toString : " +
>> userPrincipal.toString() + ".");
>>                 } else {
>>                         System.out.println("userPrincipal is null.");
>>                         request.setUserPrincipal(new
>> CoyotePrincipal(remoteUser));
>>                 }
>>                 getNext().invoke(request, response);
>>         }
>> }
> 
> 
> Please, feel free to comment this code if something looks improvable.
> 
> Thx again for your help.
> 
> Sylvain
> 
> On Fri, Sep 16, 2011 at 11:33 AM, Andr� Warnier <aw@ice-sa.com> wrote:
> 
>> Sylvain Goulmy wrote:
>>
>>> Hi everyone,
>>>
>>> I'm actually using Tomcat on my environment platform (Tomcat 5.5 / Tomcat
>>> 6
>>> and soon Tomcat 7). I have a frontend Apache http Server using the jk
>>> connector to communicate with Tomcat instance.
>>>
>>> I'd like to change this connector and use the mod_proxy one for several
>>> reasons. The main difficulty to handle is relative to the remote-user
>>> information. Indeed the jk connector automatically transmits the
>>> information
>>> so that the application can retrieve it using a request.getRemoteUser()
>>> method call.
>>>
>>> If i'm not using the ajp connector anymore, i need to handle something on
>>> the tomcat side to set the remote user in the request object. I thought i
>>> could use a valve to do this. And that's where the road ends, i have
>>> watched
>>> the ajp conenctor code in order to see how the remote user is set in the
>>> request but i can't find it.
>>>
>>>
>> You are not finding it, because you are looking in the wrong place.
>> If mod_jk can pass the authenticated user to Tomcat, via the AJP channel,
>> it is because the user (or request) has been authenticated on the Apache
>> side, before the request is forwarded through mod_jk to Tomcat.
>> The AJP connector on the Tomcat side then picks up this user-id from the
>> request coming in on the AJP channel, and sets the UserPrincipal in Tomcat
>> accordingly.
>> That's why a subsequent getRemoteUser() can pick it up in Tomcat.
>>
>> If you want to switch to mod_proxy instead of mod_jk, the question is : can
>> mod_proxy forward the Apache user-id to Tomcat ?
>> The question is slightly more complicated, because there are two methods of
>> connecting Apache to Tomcat using mod_proxy :
>> a) mod_proxy_http (protocol = HTTP, over Tomcat HTTP Connector)
>> b) mod_proxy_ajp (protocol = AJP, over Tomcat's AJP Connector (the same as
>> the one used with mod_jk)
>>
>> If you are using the second one (AJP), then we know that the AJP protocol
>> /can/ carry the Apache user-id to Tomcat (because that is what mod_jk does).
>>  The question is whether mod_proxy_ajp has some setting to tell it to do
>> that (or does it by default).
>>
>> If you are using the first one (HTTP), then one way would be to force
>> Apache to add a HTTP header to the request, containing the user-id; and on
>> the Tomcat side, have something that picks up this HTTP header, and stuffs
>> its content in the UserPrincipal object.
>> I don't know if something like that exists ready-made, but a custom Valve
>> or servlet filter should be able to do that.
>>
>>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<users-unsubscribe@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org