DO NOT REPLY [Bug 23970] New: - form-based authentication and SSL, general principles

[bu...@apache.org]

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: tomcat-dev@jakarta.apache.org
        ReportedBy: adam.hardy@cyberspaceroad.com


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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org