I have seen several developers looking for a solution for this problem: accessing session information from a different WAR (even when inside the same EAR) – here are some samples: Any way to share session state between different applications in tomcat?, Access session of another web application, different WAR files, shared resources, Tomcat: How to share data between two applications?, What does the crossContext attribute do in Tomcat? Does it enable session sharing? and so on…
From all I have searched, there are some specific solutions depending on the container, but it is somehow 'contrary to the specification'. I have also looked through Java EE specification without any luck on finding an answer.
Some developers talk about coupling between web applications, but I tend to disagree. What is the reason one would keep WARs inside the same EAR if not coupling? EJBs, for instance, can be accessed locally (even if inside another EJB JAR within the same EAR).
More specifically, one of my WARs handles authentication and authorization, and I would like to share this information with other WARs (in the same EAR). I have managed to work around similar problems before by packaging WARs as JARs and putting them into a singular WAR project (WEB-INF/lib). Yet I do not like this solution (it requires a huge effort on servlet naming and so on).
And no solution has answered the first (and most important) question: Why can't WARs share session information?
Best Answer
Treat an EAR like a pseudo-virtual machine
An EAR is simply a collection of WAR files that share common configuration and libraries, usually from JARs. This enables a collection of inter-dependent services to be managed more easily within an application container. Thus you can think of an EAR as a simple form of virtual machine once it is deployed into its container.
In the same way that one process on a virtual machine cannot affect another, the same is true for an EAR. All the WARs are isolated to protect their internal state.
Scaling authentication
In general web applications need to be stateless to scale well. Having a lot of information in the session is an anti-pattern that prevents this. This leads to a conflict between the stateless nature of HTTP and the need to maintain a speedy, customised user experience. Authentication is a classic use case, and is prevalent in chatty APIs that require a lot of authenticated requests to deliver end-user functionality.
Single Sign On and Single Sign Off need careful signalling to work correctly (consider partial Sign Off), particularly when horizontal scaling is in place. Simply sharing session state is almost never a good solution and a better approach is to use a single point of reference for the user information that all nodes in the cluster have access to.
Concentrating on speedy cached access to relevant information will yield far more scalable results than some complex, fragile session sharing solution.