tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McBride <>
Subject Re: interaction between .forward() and <security-constraint>
Date Sun, 12 Sep 2010 20:18:45 GMT
  Hi Christopher

On 09/09/2010 19:47, Christopher Schultz wrote:
> [...]
> Here's something you can do. Write a filter that you attach to URLs that
> /are/ used for authentication, and then copy the user's username into
> the session.
Yes, that's the approach I'm trying now.
> In your authentication filter, use the username stored in the session
> instead of calling request.getRemoteUser.
> Alternatively, you can wrap the request in your own wrapper and override
> getRemoteUser to get the username from the session if it's not available
> from the request.
> I'm sure there are some edge cases where an authenticated user might end
> up looking like a "guest", but you cna probably solve those.
That's a bit of a worry.   Can you say any more about the edge cases I 
should be concerned about.
>   If you
> always use HTTP Authentication (it wasn't clear what was really going
> on, with all that talk about DIGEST authentication), then you can always
> get the username from the request headers. In that case, your filter can
> use that as a source of authentication data, too.
I was hoping to use http authentication so I could use well debugged 
code rather than write my own.  But I've currently given up on that.

I wasn't happy with BASIC authentication on the grounds the password 
leaves the user's machine.  Even if its safe on the wire because of SSL, 
there is always the chance it will leak from the server end somehow.  I 
want to be sure I never know the user's actual password.

I don't want to store users passwords, I want to store some digest of 
them.   To protect against dictionary attacks on the password database I 
want to store salted passwords - i.e. add a larg'ish random number to 
each users password before taking the digest.  I couldn't see how to use 
salted password storage along with HTTP DIGEST authentication.

So I've written my own based on HTTP DIGEST but where the challenge 
includes the salt so the client can compute the users effective password.

Another variation I am trying is to associate a user not with a session 
but with an SSL session.  Each SSL session must be authenticated.  This 
prevents someone snooping/guessing the JSESSIONID ( some of my traffic 
is in clear and the JSESSIONID is therefor not secure)  and using a 
different SSL connection and faking the JSESSIONID to get access.

Thanks again for all the input.


> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAkyJK9sACgkQ9CaO5/Lv0PCyBwCfexhjBY+HPaAkrKgxonWjY/Xs
> kyEAn3OvtkaAdgoruHvSkn2oEt5HFl6z
> =dnvR
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message