tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: simple authentication question
Date Fri, 22 Feb 2013 07:51:40 GMT
Christopher Schultz wrote:
> Hash: SHA256
> André,
> On 2/21/13 6:31 AM, André Warnier wrote:
>> Christopher Schultz wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>> André,
>>> On 2/20/13 4:20 PM, André Warnier wrote:
>>>> In relation to a couple of recent posts, I have a naive
>>>> question :
>>>> In a servlet, to retrieve the authenticated user-id (if any),
>>>> I use
>>>> String userName = request.getRemoteUser();
>>>> Now, suppose I wanted to create a servlet filter which (under 
>>>> certain conditions), would force the current request to be 
>>>> authenticated as user "someuser", how would I do that ?
>>>> I s'pose it would too much to ask that it would just be
>>>> request.setRemoteUser("someuser");
>>> As long as you only want to "trick" some filter or servlet 
>>> further-down from your own, you can install a filter that:
>>> 1. Wraps the request with an HttpServletRequestWrapper which... 
>>> 2. overrides getRemoteUser() to return whatever you want it to
>>> return.
>>> If you have to pull the wool over the eyes of a Valve, you'll
>>> have to write a Valve and install it at a suitably-early in the
>>> pipeline.
>> Well,
>> Mark Thomas wrote:
>>> Almost, but you need to use a method that actually exists in the
>>> API.
>>> HttpServletRequest.login(String username, String password)
>> So it does not appear so easy after all.
>> To Mark : why "password" ? To Chris : why is that so complicated ?
> Are you saying that writing a filter is complicated? It's not so bad...
> If you want to /actually/ authenticate a user, you could write a
> Filter that simply calls login(). However, if you want to only
> masquerade as an authenticated user, I think you have to wrap the
> request as described.
> You have to do the whole Valve thing if you need to trick /Tomcat/
> into thinking that a user has been authenticated when really it hasn't
> happened because Tomcat implements container-managed authentication
> and authorization using a Valve -- and all Valves run before all
> Filters run. Thus, you have to install your fake-auth Valve before
> Tomcat's auth valve runs -- because *that* is the Valve that you have
> to trick.
>> In my idea, this thing consisted simply in "stuffing" a user-id in
>> the userPrincipal object associated to the current request.  I
>> don't really need a password, do I ? I do not really want this to
>> run again through any real authentication mechanism; I know that
>> whetever user-id I put in there is "valid enough". I know that the
>> Request itself is not modifiable, but the place where the
>> associated user-id is stored is not directly in the Request, or is
>> it ?
> Yes and no: Tomcat does whatever it wants internally. The only way to
> do what you want in a container-agnostic way is to wrap the request
> and change the behavior of getUserPrincipal: that's just how things
> are done in servlet-spec-land.
>> The idea is for example (as in a recent post to the list) : the
>> servlet filter checks that the request is coming from the internal
>> network. If so, we can just set the user-id to "internal" and let
>> it through. Otherwise, we return a 401 or a login page e.g.
> Yup, it's that simple but it can get hairy if you have to trick Tomcat
> into thinking that the user is authentication when he really isn't.
Ok, thanks.
You got it right, that is what I want to do : I wanted to trick the container into 
thinking that a regular authentication has taken place.
But in light of your explanation, it does look as if wrapping the request and changing the

behaviour of getUserPrincipal (and getRenmoteUser et al) is the way to go.

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

View raw message