On Mon, Sep 19, 2011 at 4:31 PM, Sylvain Goulmy <sygou...@gmail.com> wrote:
> 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 ...
>
Our authentification module (siteminder agent) set the remote user in the
apache request, then we use this information in a second step to
systemacally set the X-Forwarded 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.
>>
>
> 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
>>
>>
>
