Thanks Christopher. Great explanation. Finally, my problem was solved by upgrading up to Tomcat 7.0.21 On 7.0.16, my application doesn't work fine with SSL & realm ( see previous emails )
Upgrading to 7.0.21 ( clean install, really ) solved the problem and works fine. Regards 2011/9/16 Christopher Schultz <ch...@christopherschultz.net>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > André, > > On 9/16/2011 1:38 PM, André Warnier wrote: >> I guess that where the OP (and I) get a little confused is in the >> distinction between the state of "having a session" and "being >> logged-in", and maybe the sequence in which these things happen. >> >> 1) a browser sends a first request to Tomcat, and this happens to >> be directed to an application which requires authentication >> (container-driven). >> >> 2) Tomcat intercepts the request (because of the authentication >> requirement), sends back something to the browser which tells the >> browser (or the user) to supply credentials. >> >> 3) the browser (or the user) supplies the credentials along with a >> subsequent request >> >> 4) Tomcat intercepts this again, verifies the credentials, and if >> they "fit", allows the request (now "authenticated") to proceed to >> the application which had been requested in the first place. >> >> (and I know that there is some variety in the above, depending on >> the type of authentication, but roughly that's it, no ?) > > This is all correct for BASIC, FORM, and CLIENT-CERT authentication > strategies. The difference is how the server requests the credentials > and how the client provides them. > > For instance, BASIC uses a 401 server response to request credentials > and the client provides them in an WWW-Authenticate header with a > subsequent response. FORM responds with a login form and the client > sends credentials using POST or query data (aka parameters). For > CLIENT-CERT, the server requests the certificate as part of the SSL > negotiation, and the certificate is sent as part of the SSL negotiation. > >> 5) then the request hits the application, and it is the >> application which "decides" if a session is created or not. Yes ? > > Here's where things change. For FORM authentication, an HttpSession is > created and corresponds directly to the user's privileged status. Once > the HttpSession is invalidated, the login expires and the user is > logged-out. > >> And if it decides so, this creates some storage place for this >> "session thing", and makes it so that a cookie will later be sent >> back to the browser, with an id pointing to this session storage >> thing, so that a subsequent request which provides this cookie, >> allows the application to retrieve the saved session and its >> contents prior to handling the next request. > > The JSESSIONID is used to associated HttpSessions with requests. You > can have an HttpSession without having authenticated, but for a FORM > authentication, you must have an HttpSession after (and, in Tomcat, > /before/) you are successfully authenticated (Servlet spec 3.0 allows > you to perform a programmatic login, but I'll ignore that for the > purposes of this discussion). > >> Now what is maybe less clear, is whether the "session thing" which >> was created, contains or not the authentication data. > > For FORM authentication, it does. > >> And if yes : a "session invalidate" should delete the "session >> thing" (and the contained authentication info), and this should >> have the effect that when the browser sends a subsequent request, >> it will find a "no session yet" situation. > > There will be no existing session to fetch in any case. For FORM > authentication, that also means that you will have to re-authenticate > in order to get to a privileged resource again. > >> Obviously though, "no session" does not necessarily mean "not >> authenticated", but this is I believe where the OP (and I) are >> getting confused. > > For FORM authentication, no session -> not authenticated. > > Technically speaking, the servlet spec defines "being logged into an > application" as "[corresponding] precisely to there being a valid > non-null caller identity associated with the request as may be > determined by calling getRemoteUser or getUserPrincipal on the > request" (section 13.10). Tomcat implements FORM login by attaching > principal information to the session, so when the session dies, so > does the login. > > This is not the case with the other authentication mechanisms (BASIC > and CLIENT-CERT): the existence of an HttpSession for a request is > independent of the "login". This is because the client sends a > WWW-Authenticate header (for BASIC) or a client certificate (for > CLIENT-CERT) for every request after authentication. The only way to > terminate a BASIC login is to issue another 401 response, and the only > way to terminate a CLIENT-CERT login is to disrupt the SSL session (I > don't know how to do that). > > - -chris > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk5zkEEACgkQ9CaO5/Lv0PBNdACfS39J4iloiOxkFu9Ru9ncQDUS > OZIAnRLnQndKHCBeXG7dBCUG56lG/kKH > =IzSM > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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