Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to