How to handle session timeout when using Servlet 3.0 programmatic security

Question

Regarding Servlet 3.0 programmatic security, when a session times out there is no way to invoke HttpServletRequest#logout().

Does the user remain logged into JAAS?

If so, what is best practice to handle logging out of JAAS after session times out?

How does the container handle the user's subsequent request to login again and create a new session after session timeout?

As an aside, what are the pros and cons of using the following three approaches to handle session timeout when using Servlet 3.0 programmatic security:

1. HttpSessionListener#sessionDestroyed()
2. Make the @ManagedBean @SessionScoped LoginManager implement HttpSessionBindingListener and do something in valueUnbound.
3. Annotate a method in LoginManager with @PreDestroy.

Any other suggested approaches/ best practices advice would surely be appreciated.

Answer 1

There is a statement somewhere in the Servlet specification to the effect that session invalidity corresponds precisely to the state where there is no Principal in it. This is the key. logout() and timeout both invalidate the session, and invalidating the session removes the Principal from it, and all its value bindings.

All that JAAS really does is allow LoginModules to accumulate Principals in a Subject, both for the user and his roles. All that the JAAS logout() method really needs to do is clear the Subject of the Principals that were added by the same module's login(), or more probably commit(), method, and this is really just for total security if you have added things like private credentials to the Subject. As logout() won't be executed by the same instance as login()/commit(), that removal has to be based on principal class rather than on an internal collection of principals.

The JAAS logout() isn't called when the session expires, but as the Principal is removed from the session that shouldn't really matter to anybody.

If you want to track session termination for some other reason, e.g. logging, make your user bean a session binding listener and log the termination as a logout in the valueUnbound() method: this is 100% reliable in my experience.

To answer your other questions, there isn't such a state as 'logged in to JAAS': JAAS provides a login/logout service to the container, not to itself; and a new login is a new login, into a new session, whether or not the previous one expired.

Answer 2

Session management is not directly linked to JAAS.. and session management really depends on your container.

In Jetty 8, session management is handled by the SessionManager (at the context level) and SessionIdManager (at the server level).

The browser sends the session id to the server. The class implementing the SessionManager validates the session Id. If the session is expired, the session is invalidated and removed, and session listeners are notified.

I am not sure why you then need to 'logout' the user then but you should be able to hook your logout on the listeners.

'Staying logged in JAAS' may not mean much on your container. Jetty does not have a user/principals/subjects cache, so you do not 'stay logged in' unless you implement a cache yourself, as we did.

The JAAS module simply provides authentication and authorization; nothing else.

ADD

When the session is expired, the server sends a 302 back and redirects to the login page. The form submit on the page calls the Login module (which may be a JAAS Module) and upon successful authentication creates a new session and session id which is sent back to the browser usually via the mean of a cookie ( or URL rewriting).

Unless your app handles a single context id for all your contexts, I do not think you should perform any type of programmatic logout when a session expires; you may 'invalidate' an user which still has a valid session in another context.