Pid wrote: > Justin Randall wrote: >> Howdy, >> >> First, to clear an incorrect point made... >> >> There is a point of switching back to HTTP after HTTPS. From a server load >> perspective having to perform SSL computations for every single HTTP request >> can be a serious performance bottleneck. As for the security aspect, >> transmission of the username/password should be done over HTTPS, as this is >> considered "private/confidential" data and can be used to establish future >> authenticated sessions, however unless you are in a location where >> eavesdropping attacks are a risk, there is no need for encryption as the >> session ID is either a hashed string in a cookie, or the servlet is making >> use of URL re-writing, both of which are only "temporary passes" until the >> HttpSession has been invalidated. >> >> Second, to answer the question regarding actions redirect to HTTP... >> >> The reason the redirects are not going to HTTPS is because of the >> RequestDispatcher. When Tomcat sees that you are trying to access a >> resource for which login is required, it FOWARDs the request to the login >> form. The security constraints defined in web.xml are for when requests are >> made directly for those resources. What this means is that your >> configuration to make sure that the login pages use SSL only come into >> affect when the browser requests them directly. Requests that have been >> FORWARDed by the RequestDispatcher totally bypass the SSL constraints. > > False: the built-in login mechanism occurs below the level of the > Servlet Spec compliant part of the code, in the Valve processing chain > (@see org.apache.catalina.authenticator.FormAuthenticator). > > A correctly configured FORM auth, with transport-guarantee == > CONFIDENTIAL *will* pre-emptively redirect the connection to the > specified secure port, thus ensuring that the username and password is > sent over an HTTPS connection. > > In order for this to work, you need to have a correctly configured > web.xml, two connectors working including one on SSL and the correct > HTML on the form login page. > > OP, please provide: the relevant bit of your web.xml, your connector > config definitions and the HTML contents of the form on your login page. > > > We should be asking the OP for configuration details instead of > inventing technical solutions for something that should already work. > > >> What is the solution? >> >> Create a Filter subclass with the sole purpose of having its "doFilter" >> method call "sendRedirect" on the HttpServletResponse object. Map this >> Filter to the same URL pattern you use for SSL and make sure to use the >> <dispatcher> tags for FORWARD, INCLUDE, ERROR, and whatever other >> RequestDispatcher operations you want to ensure use SSL. > > False: this is spurious. > > Because the Valve operations occur below the level of Filter processing, > the dispatchers are not called when the FormAuthenticator determines > that the login page needs to be displayed. If you're using the same URL > pattern then the Valve operation will occur *before* the Filter > operation, thus rendering the Filter useless until *after* the login > completes. > > If the correct operation was to engage SSL *after* the login page had > been displayed there would be something horribly wrong with the spec or > implementation, and we'd all be moaning about it. > > > > I think the point re: going back to HTTP (after HTTPS) has already been > addressed, but I'd add the following: in many cases the computation > required to provide SSL is actually insignificant compared to the sum of > other operations required to display the contents of the page. > > It might be inconvenient to correctly configure, especially if it means > securing all other sources of displayed content, (e.g. static or cached > content), but if you want a secure site you've got to lock it down, from > top to bottom.
In fact, in regard to the email example: I think I'd rather my email was private actually, when I consider how many passwords/resets I get... p > p > > >> Hope this helps. >> >> Justin >> >>> Date: Tue, 6 Jan 2009 19:01:24 -0200 >>> From: diegogus...@gmail.com >>> To: users@tomcat.apache.org >>> Subject: Re: j_security_check with https >>> >>> this didnt work >>> >>> <security-constraint> >>> >>> <web-resource-collection> >>> >>> <web-resource-name>Usuario</web-resource-name> >>> <url-pattern>/login/*</url-pattern> >>> <http-method>POST</http-method> >>> <http-method>GET</http-method> >>> >>> </web-resource-collection> >>> <user-data-constraint> >>> >>> <transport-guarantee>CONFIDENTIAL</transport-guarantee> >>> </user-data-constraint> >>> >>> </security-constraint> >>> >>> if i try <myAPP>/login/login.jsp work, but when i try an action and >>> has restrict access, and havent user logged, tomcat redirect to login >>> page with http !!! >>> >>> 2009/1/6 Caldarale, Charles R <chuck.caldar...@unisys.com>: >>>>> From: Diego Armando Gusava [mailto:diegogus...@gmail.com] >>>>> Subject: Re: j_security_check with https >>>>> >>>>> when u login, your username and password will be transport https, but >>>>> after that, you are in http! u dont need https because, you are only >>>>> reading messages(emails) >>>> And what does that have to do with the behavior of a servlet container? >>>> >>>> - Chuck >>>> >>>> >>>> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >>>> MATERIAL and is thus for use only by the intended recipient. If you >>>> received this in error, please contact the sender and delete the e-mail >>>> and its attachments from all computers. >>>> >>>> --------------------------------------------------------------------- >>>> 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 >>> >> _________________________________________________________________ >> Keep in touch and up to date with friends and family. Make the connection >> now. >> http://www.microsoft.com/windows/windowslive/ > > > --------------------------------------------------------------------- > 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
