On Mon, Sep 19, 2011 at 2:43 PM, André Warnier <a...@ice-sa.com> wrote:
> 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 ?
>
I'm using the RequestHeader directive :
RequestHeader set X-Forwarded-User ...
>
> 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.
>
I have taken this aspect in consideration, but as you said, it worths
mentionning it ;-)
>
>
>
> 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 <a...@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.**apa**che.org<http://apache.org>
>>> <users-unsubscribe@**tomcat.apache.org<users-unsubscr...@tomcat.apache.org>
>>> >
>>>
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> users-unsubscribe@tomcat.**apache.org<users-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
