Hi Christopher
On 09/09/2010 19:47, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
[...]
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.
Brian
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkyJK9sACgkQ9CaO5/Lv0PCyBwCfexhjBY+HPaAkrKgxonWjY/Xs
kyEAn3OvtkaAdgoruHvSkn2oEt5HFl6z
=dnvR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
