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.
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|