tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pid...@pidster.com>
Subject Re: j_security_check with https
Date Wed, 07 Jan 2009 10:02:14 GMT
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.

p


> Hope this helps.
> 
> Justin
> 
>> Date: Tue, 6 Jan 2009 19:01:24 -0200
>> From: diegogusava@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.Caldarale@unisys.com>:
>>>> From: Diego Armando Gusava [mailto:diegogusava@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-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
>>
> 
> _________________________________________________________________
> 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message