logout method

[gmansoor]

Hi Ben,

May be I haven't paid attention to this, but I could not find a consistent way of logout in the Acegi Security System.
I know what needs to be done at the time of logout (setting Context.setAuthentication(null), remove the ACEGI context from HttpSession) etc but I think it should be the part of common code that everyone can use rather than everyone write their own code.

May be AuthenticationManager should have logout method in addition to authenticate that does this cleanup or somewhere else in any helper classes. Infact, it should have 2 methods logout() and logout(HttpServletRequest), so that appropriate methods could be called by the user depending upon how the Acegi is being used.

In our application, we had to provide a consistent way to be used from both web and non-web based application. So, I had to introduce another class (called LoginManager) to have both authenticate and logout methods for both web and non-web clients. Methods that have HttpServletRequest parameter do the same as other method with this param but extra stuff that do specific to the web. For example, in case of authenticate, it also set the webAuthenticationDetails, in case of logout, method with request do cleanup from the session also.

These are just my observations and the way I create wrapper against the Acegi authentication...

What do you think? Do you think, is this something worth integrating to Acegi?

[Ben Alex]

HttpSession invalidation is not a requirement of Acegi Security. All we need is the ContextHolder to contain a null Authentication in order to stop a given Authentication being used internally by Acegi Security to process requests made by a principal. HttpSessionContextIntegrationFilter will happily store the null Authentication in the HttpSession at the end of the request, so the principal is still logged out.

I am reluctant to introduce web-specific objects to the AuthenticationManager interface, which is currently free of them. The other issue is Acegi Security doesn't really have a role to play in HttpSession invalidation - it's more an issue for the application programmer who wants to keep their Servlet Container resources optimised. Finally, some authentication mechanisms are incompatible with the notion of logging out. For example, how do we notify a CAS 2 server the user has logged out (we can't) and tell a user agent to stop presenting BASIC credentials. Or tell a remote rich client or web service they have logged out. I think logout would confuse users when the notion of logging out is so authentication mechanism specific.

[gmansoor]

I agree with your points but if the term logout is confusing, it could be something else, cleanup() or anything....

How about introducing this cleanup/logout in the AuthenticationProvider as well, then if CAS does not have anything specfic to logout, they will just not implement it.

BTW, setting ContextHolder.setContext(null) do cause a problem. As HttpSessionContextIntegrationFilter complains as it is expecting that valid Context exists (at the time of post request), So to get it working, it should be context.setAuthentication(null).

[wfcheang]

Just curious, why can't you just invalidate the session?

[Ben Alex]

How about introducing this cleanup/logout in the AuthenticationProvider as well, then if CAS does not have anything specfic to logout, they will just not implement it.

I think if a "cleanup" were to be introduced, it would be better placed with the authentication mechanisms. An authentication mechanism refers to the "credentials delivery approach" to the ContextHolder, such as BASIC, form, digest, CAS etc. An authentication manager/provider, on the other hand, is usually used to validate what it finds on the ContextHolder and populates it with the required authorities.

Perhaps there is some merit in introducing a static method on each authentication mechanism filter to facilitate logout. Alternatively, we could extend SecureContext to introduce a "terminateAuthentication" boolean property, which, if true, would signal to authentication mechanisms after the filter chain has returned that the ContextHolder should be cleaned up and any authentication mechanism-specific notifications performed. Some authentication mechanisms will ignore terminateAuthentication (eg the anonymous processing system). This is probably the place to hook a logout event or similar as well.

The problem with all of this is that no one size fits all authentication mechanisms. Whatever strategy is ultimately adopted will invariably be unsuitable for some yet-to-be-supported authentication mechanism. If you introduce any form of logout handling, end users will expect it work with everything. I can see scope creep happening here. Right now all we need to do is null the Authentication inside the ContextHolder, which is pretty easy to do. Even HttpSession invalidation is out-of-scope, as in certain cases (eg BASIC authentication) the recommended approach is to disable the creation of HttpSessions by HttpSessionContextIntegrationFilter anyway.

BTW, setting ContextHolder.setContext(null) do cause a problem. As HttpSessionContextIntegrationFilter complains as it is expecting that valid Context exists (at the time of post request), So to get it working, it should be context.setAuthentication(null).

From 0.9.0 (and current CVS) it's actually SecurityContextHolder.getContext().setAuthenticati on(null).

[jvargas]

I am not sure how related this issue is, but when writing code for "logout" i realized that the after reloading tomcat the user is still authenticated and is able to view secure pages. Should my logout/cleanup method be able to fix this?


FYI: My authentication processing filter uses this following as its rememberMeServices property.

<bean id="rememberMeServices" class="net.sf.acegisecurity.ui.rememberme.NullRememberMeServices"/>

[Ben Alex]

If you take a look at the Contacts sample application, it provides a logout.jsp. IIRC Tomcat serializes the HttpSessions in memory at time of shutdown to disk, so when you restart it any web requests presenting the same jsessionid will be treated as if Tomcat had never shutdown.