Why Did Our CAS Login Fail? Uncovering Session Sharing Issues and Fixes

Problem Background

On July 3 a new CAS extension was released and users quickly reported two symptoms: unrecognized tickets and redirection to the login page.

Investigation

The server configuration parameters were correct, so the focus shifted to the second symptom. Logs showed no errors, and the issue appeared intermittently when the browser received a 302 redirect instead of a proper authentication‑failure response.

Further checks confirmed that Nginx and DNS were correctly configured, and the problem persisted across multiple servers, suggesting a session‑related cause.

JSESSIONID Basics

When a client first accesses the server, the response includes a Set‑Cookie header containing a JSESSIONID. The browser stores this cookie and sends it back with every subsequent request, allowing the server to locate the corresponding session.

On the second request the same JSESSIONID is sent, enabling the server to retrieve the session data.

CAS Session Sharing

CAS uses MemoryCache to share sessions across Tomcat nodes. The flow is:

Client calls Service A.

Service A creates a session; its JSESSIONID includes a random part and the MemoryCache node alias.

Service A stores the session in MemoryCache and returns the JSESSIONID to the client.

Client includes this JSESSIONID in subsequent requests, which may reach Service B.

Service B checks its local session; if missing, it retrieves the session from MemoryCache.

If MemoryCache also lacks the session, Service B creates a new one.

During the incident the response contained a different JSESSIONID from the request, indicating that sessions were not being shared.

Scenarios Illustrating the Issue

Four typical request patterns were described, showing how a missing MemoryCache configuration on one node leads to session loss and authentication failures.

Resolution

The root cause was identified as a newly added server that lacked the MemoryCache configuration. Removing this node restored proper session sharing, and the login process worked again.

Because CAS tickets are also stored in MemoryCache, the missing cache caused ticket validation failures, which explained the first symptom.

Further Discussion

Why are cookies and sessions needed? HTTP is stateless, so sessions (server‑side) and cookies (client‑side) provide a way to associate multiple requests with the same user.

JSESSIONID generation is random, with the suffix indicating the MemoryCache node.

Common session problems include hijacking, server memory pressure, and lack of sharing across nodes.

If you have other questions, feel free to leave a comment.