Re: j_security_check with https
Hi Justin, On Wed, Jan 7, 2009 at 4:13 AM, Justin Randall ran...@hotmail.com wrote: 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. You've got any example using this solution? Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check with https
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: 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-nameUsuario/web-resource-name url-pattern/login/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/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
Re: j_security_check with https
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-nameUsuario/web-resource-name url-pattern/login/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/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
RE: j_security_check with https
Hello,
I'm not going to bother responding to the many posts that said the solution I
mentioned was wrong, instead I'll just provide the example of how to do it,
since it works.
. lines removed .
package blah;
. lines removed .
public final class SomeFilterClass implements Filter {
. lines removed .
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse rsp = (HttpServletResponse) response;
rsp.sendRedirect(req.getRequestURI());
filterChain.doFilter(request, response);
}
. lines removed .
}
=
And below is what the web.xml looks like:
=
lines removed .
filter
filter-nameSomeFilterClass/filter-name
filter-classblah.SomeFilterClass/filter-class
/filter
filter-mapping
filter-nameSomeFilterClass/filter-name
url-pattern/ssl/*/url-pattern
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
. lines removed .
security-constraint
web-resource-collection
web-resource-nameRequiresLogin/web-resource-name
url-pattern/html/*/url-pattern
/web-resource-collection
auth-constraint
role-namesomerole/role-name
/auth-constraint
/security-constraint
security-constraint
web-resource-collection
web-resource-nameRequiresSSL/web-resource-name
url-pattern/ssl/*/url-pattern
/web-resource-collection
user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint
security-role
role-namesomerole/role-name
/security-role
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/ssl/login.jsp/form-login-page
form-error-page/ssl/login-error.jsp/form-error-page
/form-login-config
/login-config
. lines removed .
=
Of course you'll need to change the login/security constraint URLs and role
name to match those in your environment.
For anyone who stated the earlier statements were incorrect, I encourage you to
provide another better working example. This one works for me and is used by
other industry professionals.
Regards,
Justin
Here is an example:
Date: Wed, 7 Jan 2009 09:35:33 +0100
From: rc4...@googlemail.com
To: users@tomcat.apache.org
Subject: Re: j_security_check with https
Hi Justin,
On Wed, Jan 7, 2009 at 4:13 AM, Justin Randall ran...@hotmail.com wrote:
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.
You've got any example using this solution?
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
-
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/
Re: j_security_check with https
Justin Randall wrote:
Hello,
I'm not going to bother responding to the many posts that said the solution I
mentioned was wrong, instead I'll just provide the example of how to do it,
since it works.
. lines removed .
package blah;
. lines removed .
public final class SomeFilterClass implements Filter {
. lines removed .
public void doFilter(ServletRequest request, ServletResponse response,
FilterChain filterChain) throws IOException, ServletException {
HttpServletRequest req = (HttpServletRequest) request;
HttpServletResponse rsp = (HttpServletResponse) response;
rsp.sendRedirect(req.getRequestURI());
filterChain.doFilter(request, response);
}
. lines removed .
}
=
And below is what the web.xml looks like:
=
lines removed .
filter
filter-nameSomeFilterClass/filter-name
filter-classblah.SomeFilterClass/filter-class
/filter
filter-mapping
filter-nameSomeFilterClass/filter-name
url-pattern/ssl/*/url-pattern
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
. lines removed .
security-constraint
web-resource-collection
web-resource-nameRequiresLogin/web-resource-name
url-pattern/html/*/url-pattern
/web-resource-collection
auth-constraint
role-namesomerole/role-name
/auth-constraint
/security-constraint
security-constraint
web-resource-collection
web-resource-nameRequiresSSL/web-resource-name
url-pattern/ssl/*/url-pattern
/web-resource-collection
user-data-constraint
transport-guaranteeCONFIDENTIAL/transport-guarantee
/user-data-constraint
/security-constraint
security-role
role-namesomerole/role-name
/security-role
login-config
auth-methodFORM/auth-method
form-login-config
form-login-page/ssl/login.jsp/form-login-page
form-error-page/ssl/login-error.jsp/form-error-page
/form-login-config
/login-config
. lines removed .
=
Of course you'll need to change the login/security constraint URLs and role
name to match those in your environment.
For anyone who stated the earlier statements were incorrect, I encourage you
to provide another better working example. This one works for me and is
used by other industry professionals.
Your example is mostly correct, in that you have the transport guarantee
in place for a given path which will force a redirect to the configured
HTTPS port; it's just that the additional filter is surplus.
Thus the first example I gave would seem to be an improvement.
It is also used by 'industry professionals' and works perfectly well for me.
Am happy to be corrected if I'm wrong.
p
Regards,
Justin
Here is an example:
Date: Wed, 7 Jan 2009 09:35:33 +0100
From: rc4...@googlemail.com
To: users@tomcat.apache.org
Subject: Re: j_security_check with https
Hi Justin,
On Wed, Jan 7, 2009 at 4:13 AM, Justin Randall ran...@hotmail.com wrote:
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.
You've got any example using this solution?
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
-
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
Re: j_security_check with https
i dont know how to request j_security_check on https! i attemped http://wiki.apache.org/tomcat/SSLWithFORMFallback but didnt work login-config !--auth-methodFORM/auth-method-- form-login-config form-login-page/login.do/form-login-page form-error-page/login/loginError.jsp/form-error-page /form-login-config /login-config tomcat redirect to Http! cheers - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check with https
Diego Armando Gusava wrote: i dont know how to request j_security_check on https! i attemped http://wiki.apache.org/tomcat/SSLWithFORMFallback but didnt work I think the above attempts to find an SSL cert, but falls back to FORM auth. Which isn't perhaps what you want? login-config !--auth-methodFORM/auth-method-- form-login-config form-login-page/login.do/form-login-page form-error-page/login/loginError.jsp/form-error-page /form-login-config /login-config Set transport-guaranteeCONFIDENTIAL/transport-guarantee in the security constraint section, as below. Ensure that you have an SSL enabled connector and that the redirect port on the normal connector matches the SSL port. security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/mySecurePath//url-pattern http-methodGET/http-method ... http-methodPOST/http-method /web-resource-collection auth-constraint role-namerolename/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint p tomcat redirect to Http! cheers - 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
Re: j_security_check with https
let me explain when i try to access mySecurePath for example, tomcat show me a login page with https but after that i dont need for example be with https, because i only need to send protected username and password. i want to only need login.jsp with https!! 2009/1/6 Pid p...@pidster.com: Diego Armando Gusava wrote: i dont know how to request j_security_check on https! i attemped http://wiki.apache.org/tomcat/SSLWithFORMFallback but didnt work I think the above attempts to find an SSL cert, but falls back to FORM auth. Which isn't perhaps what you want? login-config !--auth-methodFORM/auth-method-- form-login-config form-login-page/login.do/form-login-page form-error-page/login/loginError.jsp/form-error-page /form-login-config /login-config Set transport-guaranteeCONFIDENTIAL/transport-guarantee in the security constraint section, as below. Ensure that you have an SSL enabled connector and that the redirect port on the normal connector matches the SSL port. security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/mySecurePath//url-pattern http-methodGET/http-method ... http-methodPOST/http-method /web-resource-collection auth-constraint role-namerolename/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint p tomcat redirect to Http! cheers - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check with https
orm Based Authentication has the same lack of security as Basic Authentication since the user password is transmitted as plain text and the target server is not authenticated. Again additional protection can alleviate some of these concerns: a secure transport mechanism (HTTPS). i want secure transport mechanism (HTTPS) how can i do it? 2009/1/6 Diego Armando Gusava diegogus...@gmail.com: let me explain when i try to access mySecurePath for example, tomcat show me a login page with https but after that i dont need for example be with https, because i only need to send protected username and password. i want to only need login.jsp with https!! 2009/1/6 Pid p...@pidster.com: Diego Armando Gusava wrote: i dont know how to request j_security_check on https! i attemped http://wiki.apache.org/tomcat/SSLWithFORMFallback but didnt work I think the above attempts to find an SSL cert, but falls back to FORM auth. Which isn't perhaps what you want? login-config !--auth-methodFORM/auth-method-- form-login-config form-login-page/login.do/form-login-page form-error-page/login/loginError.jsp/form-error-page /form-login-config /login-config Set transport-guaranteeCONFIDENTIAL/transport-guarantee in the security constraint section, as below. Ensure that you have an SSL enabled connector and that the redirect port on the normal connector matches the SSL port. security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/mySecurePath//url-pattern http-methodGET/http-method ... http-methodPOST/http-method /web-resource-collection auth-constraint role-namerolename/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint p tomcat redirect to Http! cheers - 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: j_security_check with https
From: Diego Armando Gusava [mailto:diegogus...@gmail.com] Subject: Re: j_security_check with https when i try to access mySecurePath for example, tomcat show me a login page with https but after that i dont need for example be with https, because i only need to send protected username and password. i want to only need login.jsp with https!! You cannot switch a secure (HTTPS) session to an insecure transport (HTTP) - your login would be worthless if you could. Once you log in via SSL, you'll need to stay with HTTPS to utilize the session. - 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
Re: j_security_check with https
no man, example, email 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) 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 i try to access mySecurePath for example, tomcat show me a login page with https but after that i dont need for example be with https, because i only need to send protected username and password. i want to only need login.jsp with https!! You cannot switch a secure (HTTPS) session to an insecure transport (HTTP) - your login would be worthless if you could. Once you log in via SSL, you'll need to stay with HTTPS to utilize the session. - 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
Re: j_security_check with https
On Tue, Jan 6, 2009 at 9:13 PM, Diego Armando Gusava diegogus...@gmail.com wrote: no man, example, email 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) Then just phrase your url-pattern in your security-constraint-section accordingly - should work. Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: j_security_check with https
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
Re: j_security_check with https
this didnt work security-constraint web-resource-collection web-resource-nameUsuario/web-resource-name url-pattern/login/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/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
Re: j_security_check with https
Gregor Schneider wrote: On Tue, Jan 6, 2009 at 9:13 PM, Diego Armando Gusava diegogus...@gmail.com wrote: no man, example, email 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) Then just phrase your url-pattern in your security-constraint-section accordingly - should work. It won't. Tomcat won't let a session created under HTTPS transition to HTTP as the session ID is effectively the password. If the password needed HTTPS then the session ID does too. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: j_security_check with https
My question is how to combine the form based authentication, where we use jsecuritycheck , jusername etc with https. As far as I know if we use form based authentication username and password will be authenticated by the container managed resource called 'jsecuritycheck. But the data transfer from client browser to tomcat will be still a plain text. i want to encrypt this and obviously i need to use https. So how to combine both and how tomcat wil help me doping this?? 2009/1/6 Mark Thomas ma...@apache.org: Gregor Schneider wrote: On Tue, Jan 6, 2009 at 9:13 PM, Diego Armando Gusava diegogus...@gmail.com wrote: no man, example, email 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) Then just phrase your url-pattern in your security-constraint-section accordingly - should work. It won't. Tomcat won't let a session created under HTTPS transition to HTTP as the session ID is effectively the password. If the password needed HTTPS then the session ID does too. Mark - 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
RE: j_security_check with https
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. 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. 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-nameUsuario/web-resource-name url-pattern/login/*/url-pattern http-methodPOST/http-method http-methodGET/http-method /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/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/
RE: j_security_check with https
From: Justin Randall [mailto:ran...@hotmail.com] Subject: RE: j_security_check with https 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. Of course - everyone recognizes that. Serious sites will offload the SSL processing to a separate box or NIC card for that very reason. however unless you are in a location where eavesdropping attacks are a risk, Such as pretty much anywhere on the Internet? If eavesdropping attacks were not a risk, there would be no point in encrypting the security credentials. You can't have it both ways. - 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
