Question

Right now we’re developing a big application, where the modules are deployed as single .EAR files (each containing a .WAR and a EJB .JAR).

We configure in GlassFish 3.1 the applications to have Single Sign On using JAAS. So we require to keep alive every web module session while the SSO session is alive.

An example could be: Modules A, B and C are deployed with a 10-minute session. The user signs on using A, then can navigate to B and C, and spend (let’s assume) 20 minutes on C.

The idea is that while the user is only using C, we must keep alive his session (including managed beans) on A and B.

What could help us to achieve this? an idea is to create a servlet on each module to touch the session (thus keeping it alive), and send asynchronous (one-way possibly?) requests to those servlets from the module the user is using, but it seems a little overkill to open HTTP connections (over TCP) each time the user do something. Maybe a polling could help here, but we would like to avoid this kind of communication.

Another idea is using a shared memory cache, and a cache listener to touch the other sessions, doing a lookup with the session id; could this do the trick with better performance?

We’re open to any ideas… except using another application servers (we must use OpenSource GlassFish – no Coherence*Web).

Thank you for your time.

Answer 1

Do you require JAAS? You can implement a solution using spring-security, and a backing redis cache for the sessions ids. so e.g. when user is logged in on A, a session-id is put into the redis cache, when the user navigates to B through a link that passes a session id as a query parameter, the spring security layer (on B) will make sure that the session-id is alive and valid in the redis cache. Redis has built-in support for expiring data

This is a good article: http://www.infoq.com/minibooks/Identity-Management-Shoestring on building a Central Authentication Services (CAS).

Hope this helps