tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid <>
Subject Re: interaction between .forward() and <security-constraint>
Date Mon, 06 Sep 2010 16:22:00 GMT
On 06/09/2010 16:04, Brian McBride wrote:
>  Thanks to all who have responded.  The advice and comments have been
> very helpful.
> For my application, the MIM vulnerability is a concern, so I expect to
> be using HTTPS for at least some of the traffic.  Next steps are to
> clarify my confidentiality requirements and see what I can find on the
> performance implications of using HTTPS, i.e. is it cheap enough that I
> don't have to worry about using it for all traffic.

Assuming you're not running on hamster powered servers, yes, with modern
software & hardware it's quite cheap.


> Brian
> On 04/09/2010 17:27, André Warnier wrote:
>> Brian McBride wrote:
>> ...
>>> Ok - now to figure out how to implement digest authentication ...
>> Digest authentication is not very popular, and rather a pain to
>> implement yourself.
>> The reason why it is not very popular is that it is a bit of a halfway
>> solution : it does avoid user passwords to be transmitted in clear
>> over the net, but it is not safe for man-in-the-middle attacks
>> (someone can record the digest, and use it to authenticate later as
>> that user).  And it still leaves the subsequent conversation unencrypted.
>> If you really need security, then you should run your entire site
>> under HTTPS.
>> This will also allow you to do Basic authentication, or form-based
>> authentication, since the authentication dialog is encrypted anyway by
>> the HTTPS connection.
>> Maybe also your needs would be a valid reason to use an Apache httpd
>> front-end for your site, taking care of the HTTPS side and/or the
>> authentication.  httpd can then authenticate the user (using pretty
>> much any method of your choice, there are standard modules available
>> for all), and just pass the already-authenticated user-id to Tomcat.
>> Tomcat can then just do the access-control part.
>> (or if you prefer, you could even do that at the Apache httpd level
>> also).
>> In this case the added overhead would be minimal, because what you do
>> at the httpd level, you do not need to do at the Tomcat level and
>> vice-versa.
>> It is all basically a matter of preference.  Not being myself a Tomcat
>> or Java guru, I prefer to do these things at the Apache httpd level,
>> and keep the Tomcat side simple.
>> Your mileage may vary.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message