Re: Example to logout on Tomcat 7 and SSL + Realm [SOLVED]

[Chema <de...@gmail.com>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org