-----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
