DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23970>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23970 form-based authentication and SSL, general principles Summary: form-based authentication and SSL, general principles Product: Tomcat 5 Version: 5.0.12 Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Unknown AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] In TC5 I believe it was decided to remove the ability to specify SSL constraints on the FORM-based login & error pages themselves. Developing my app in TC4, I used this technique to encrypt the login page, and switch back to HTTP immediately after. I have 3 levels of security in my web-app: 1st level pages, which are public and require no security 2nd level pages, where users must log in, using an encrypted login form 3rd level pages, which need SSL. To deter session-hijackers when moving from level 2 to level 3, I invalidate the session and cause a new login request and only after that does the session stay in SSL. This is the current paradigm for web security in e-commerce - witness eBay or Amazon. I believe from what I have picked up so far in the TC mailing lists, that the change was done to refine the TC5 implementation of the Servlet 2.4 spec. It creates a new security paradigm. Now only logins to pages protected by constraints specifying a transport guarantee of 'confidential' will have login forms encrypted. A login deemed to require encryption is deemed to require encryption on all of its protected pages. This is a measure against session-hijacking. The adoption of this paradigm in TC5 has resulted in 2 issues for me: (1) it has broken my application security in a such a way that a redesign of the security is necessary (2) it seems to be forcing me either to use this new paradigm (i.e. all SSL sessions after login), or to drop CMS entirely. I cannot find a way to protect my app with non-encrypted CMS and encrypted form-based authentication. Committing additional resources to run SSL sessions is a risk I do not wish to take in terms of my business strategy. I only started out on this current project with so much time & money, and now the hill I have to climb seems to be getting steeper. What I would like, and I expect you will see others ask for it too, is an option to set encryption on the login form whatever the transport guarantee for the protected page, or of course the re-instatement of the use of constraints on the login pages. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
