Re: Force Non-SSL
Greetings: As promised, i report back my solutions and hope this may help others. On Mon, 2005-06-06 at 07:42 -0600, Duong BaTien wrote: On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote: Almost. (I think) Thanks. I will try the workaround and report to the list for the benefits of others. BaTien DBGROUPS You can't request any pages under /WEB-INF. Security constraints are only for the incoming URL - not urls obtained by getRequestDispatcher() -Tim I know. These are my protected pages and i want to make sure that they must go through my presentation engine (Jsf + Tiles). BaTien Duong BaTien wrote: On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/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 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The re direct must include both desired protocol and service port as explained in a proposed solution by Steve Ditlinger in his JavaWorld paper (Feb 2002) and later evolved into sslext for Struts. The approach is quite easy to implement for any framework. This is what we do under Jsf. The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. The desired protocol and service port must be explicitly specified for the requested page. Hope this may help and/or save others some time. BaTien DBGROUPS 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
Almost. (I think) You can't request any pages under /WEB-INF. Security constraints are only for the incoming URL - not urls obtained by getRequestDispatcher() -Tim Duong BaTien wrote: On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/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 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
On Mon, 2005-06-06 at 07:04 -0400, Tim Funk wrote: Almost. (I think) Thanks. I will try the workaround and report to the list for the benefits of others. BaTien DBGROUPS You can't request any pages under /WEB-INF. Security constraints are only for the incoming URL - not urls obtained by getRequestDispatcher() -Tim I know. These are my protected pages and i want to make sure that they must go through my presentation engine (Jsf + Tiles). BaTien Duong BaTien wrote: On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/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 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
On Thu, 2005-05-26 at 06:34 -0400, Tim Funk wrote: From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim Hello Tim and other tomcat 5.5.9 experts: If i understand you correctly, you propose: 1) set security constraint pages you want to run under ssl, such as: security-constraint web-resource-collection url-pattern/WEB-INF/secure/*/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 2) Write a servlet filter to direct any url NOT under the pattern /WEB-INF/secure/* to the same url such as /public/123.jsp. Do you have this code handy and want to share with others? The result will be: 1) When a user requests a /WEB-INF/secure/logonSuccess.jsp the container will force the user with its logon FORM, if the user is not authenticated. If username/password is authenticated the page logonSuccess.jsp wil be served. 2) If you create a user session (e.g. a guestTag for collecting user activities) while user is NOT authenticated, and the container now authenticated the user after the request of logonSuccess.jsp, the servlet spec will guarantee that the session visible to developer code after login be the same session object that was created prior to SSL login so there is no loss of session information. 3) Since the security model does not apply to RequestDispatcher according to serlet spec, the container will serve other requests under standard http and NOT https as reported after the user was served the logonSuccess.jsp. 4) Only after the user is authenticated by the server, we can use getUserPrincipal(), isUserInRole() to integrate container authentication with programmatic authorization. Before that, only a generic guestTag for recording user activities. Do i miss something? Thanks BaTien DBGROUPS August Detlefsen wrote: Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. --- Tim Funk [EMAIL PROTECTED] wrote: no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Force Non-SSL
Not dreaming for a second of contradicting Tim ;) but wouldn't this work? Switch on SingleSignOn. Install two hosts on the same engine. First host has non-ssl connector only, second has ssl only. Install main webapp on non-ssl host, without the login code. Install just the login code on a simplified webapp on the other host, and add a simple invoker servlet (or similar) to redirect all other requests to urls on the main host. It's not exactly trivial or elegant, and having to switch on SingleSignOn might be a problem in some apps, but could it work? I have been advised by a trusted friend experienced in these matters that these sorts of config are better tackled by fronting your site with apache, and using mod_rewrite to enforce the ssl vs no-ssl requirements. -Original Message- From: August Detlefsen [mailto:[EMAIL PROTECTED] Sent: Thursday 26 May 2005 01:43 To: Tomcat Users List Subject: Re: Force Non-SSL Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. --- Tim Funk [EMAIL PROTECTED] wrote: no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
From a config point of view no. The simple workaround - Ditch the web.xml config for requiring SSL - Create a filter which checks the scheme and URL - if the do not match what you desire - you can issue a redirect in the filter to https (or http) as desired -Tim August Detlefsen wrote: Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. --- Tim Funk [EMAIL PROTECTED] wrote: no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. --- Tim Funk [EMAIL PROTECTED] wrote: no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
Since there is no way to maintain the session without hacking Tomcat, as Tim said no. But what you could try is a single use password. User hits the SSL encrypted login page. User authenticates with normal username and password. Random string password is created and stored in database and put in query string. User then is redirected to the unencrypted jsp login page that pulls the password from the request query string and inserts it into the form. The page does a submit on load. (JavaScript onload in the body tag) Once the user is logged in the password would need deleted from the database and replaced with normal password. So the user logs in with the normal password. It is the swapped for the single use password. Once logged in with the single use password it is replaced with the normal password. Now the question is how bad did you want this? And no I have not done this, so it is all theory at this point. Doug - Original Message - From: August Detlefsen [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Wednesday, May 25, 2005 8:43 PM Subject: Re: Force Non-SSL Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. --- Tim Funk [EMAIL PROTECTED] wrote: no -Tim August Detlefsen wrote: In my webapp I force clients to use SSL encryption for logins with a security constraint and transport-guarantee elements like this: security-constraint web-resource-collection web-resource-nameLogin/web-resource-name url-pattern/login/*/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint However, once a user hits the login page, every subsequent page also uses https. Is there a way to force them back to regular http once they leave the login section? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Force Non-SSL
August Detlefsen wrote: Is there no way to do it? SSL creates a lot of overhead for a site that is serving up 100MB image files. There are ugly or less ugly workarounds, like the one yahoo uses. Login can go against HTTPS, sets up it's version of session and then redirects the user to HTTP. There the server will pickup the user via a cookie or a URL containing yahoo's session. From there on, yahoo can use any session mechanism it likes. This, of course cannot be coupled with HTTP AUTH Basic. It is outside of that spec. Nix. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
