- Welcome to Part 2 of the Authentication & Identity Security series.
- This article explains how applications remember users after successful login.
- Designed for Middleware, DevOps, Cloud, and Application Support Engineers.
- Includes enterprise examples using WebSphere, Tomcat, JBoss, IBM HTTP Server, NGINX, and Load Balancers.
Table of Contents
- Introduction
- What is a Session?
- How WebSphere, JBoss, Tomcat & Docker Store Session Data
- What is a Cookie?
- What is JSESSIONID?
- How Session Management Works
- Enterprise Example: WebSphere Session Flow
- Sessions Through Load Balancers
- Session vs Cookie vs JSESSIONID
- Session Security Best Practices
- Common Session Issues
- Key Takeaways
- What’s Next?
Introduction
In Part 1, we learned that authentication verifies a user's identity. After authentication is successful, the next important question is: how does the application remember the same user during future requests?
This is where Sessions, Cookies, and JSESSIONID come into the picture. These components help enterprise applications maintain user identity after login without asking the user to authenticate again on every page.
Authentication verifies the user once, while session management maintains the user's identity throughout the application journey.
What is a Session?
A session is a server-side mechanism used to store user-specific information after successful authentication.
When a user logs in, the application server creates a unique session for that user. The session may store information such as:
- User ID
- User role
- Login time
- Application permissions
- User preferences
The session remains active until one of the following events occurs:
- User logs out
- Session timeout occurs
- Application server restarts
- Session is invalidated by the application
In WebSphere, JBoss, and Tomcat, sessions are usually stored in application server memory unless session persistence or replication is configured.
How Do WebSphere, JBoss, Tomcat & Docker Store Session Data?
By default, Java application servers store session data in JVM heap memory. The browser only stores the session identifier (JSESSIONID), while the actual user session data remains on the application server.
| Platform | Default Session Storage | High Availability Options |
|---|---|---|
| IBM WebSphere | JVM Heap Memory | Memory-to-Memory Replication, Database Persistence |
| JBoss EAP / WildFly | JVM Heap Memory | Session Replication, Infinispan Cache |
| Apache Tomcat | JVM Heap Memory | Session Persistence, Redis, Session Replication |
| Docker Containers | Inside Application JVM/Process | Redis, Database, Sticky Sessions, External Session Store |
Docker Session Storage
Browser │ JSESSIONID │ Docker Container │ Tomcat / JBoss / WebSphere Liberty │ JVM Heap Memory
Docker itself does not manage user sessions. Sessions are managed by the application running inside the container.
If a container is restarted, redeployed, or scaled down, in-memory sessions may be lost unless external session storage is configured.
Use Redis, database persistence, sticky sessions, or JWT-based authentication for better scalability and resilience.
What is a Cookie?
A cookie is a small piece of data stored in the user's browser. Applications use cookies to identify users across multiple HTTP requests.
HTTP is stateless by default. This means every request is independent. Without cookies or tokens, the server cannot easily identify whether two requests are coming from the same user.
After successful login, the server sends a cookie to the browser.
Set-Cookie: JSESSIONID=ABC123XYZ789
For every next request, the browser automatically sends this cookie back to the server.
Cookie: JSESSIONID=ABC123XYZ789
What is JSESSIONID?
JSESSIONID is the default session identifier used by Java-based application servers.
It is commonly seen in applications running on:
- IBM WebSphere Application Server
- WebSphere Liberty
- Apache Tomcat
- JBoss EAP
- WildFly
JSESSIONID does not usually store the full user data. It acts as a reference ID that helps the application server locate the correct server-side session.
JSESSIONID=ABC123XYZ789
The actual session data is normally stored on the server side. The browser usually stores only the session identifier.
How Session Management Works
User │ ▼ Login Page │ ▼ Authentication Successful │ ▼ Application Server Creates Session │ ▼ JSESSIONID Generated │ ▼ Cookie Sent To Browser │ ▼ Browser Sends Cookie With Every Request │ ▼ Application Server Retrieves Session │ ▼ User Continues Application Access
This process allows the application to remember the authenticated user until logout or session timeout.
Enterprise Example: WebSphere Session Flow
Architecture
User Browser
│
▼
IBM HTTP Server
│
▼
WebSphere Application Server
│
▼
Enterprise Application
Session Flow
- User accesses the application login page.
- User enters username and password.
- WebSphere authenticates the user using LDAP or Active Directory.
- WebSphere creates a session in application server memory.
- WebSphere generates a JSESSIONID.
- Browser receives the JSESSIONID as a cookie.
- Browser sends the same cookie in every future request.
- WebSphere uses JSESSIONID to locate the user's session.
Example HTTP Response
HTTP/1.1 200 OK Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/app; HttpOnly; Secure
Example HTTP Request
GET /app/dashboard HTTP/1.1 Host: www.company.com Cookie: JSESSIONID=ABC123XYZ789
Sessions Through Load Balancers
In enterprise environments, applications often run on multiple servers behind a load balancer.
User Browser
│
▼
NGINX / IBM HTTP Server / F5 / Azure Load Balancer
│
▼
┌───────────────┬───────────────┐
│ WebSphere-01 │ WebSphere-02 │
└───────────────┴───────────────┘
If a user logs in through WebSphere-01 but the next request goes to WebSphere-02, the session may not be available on WebSphere-02 unless session replication or sticky session is configured.
Common Solutions
- Sticky Session: Route the same user to the same backend server.
- Session Replication: Copy session data across cluster members.
- External Session Store: Store sessions in Redis, database, or distributed cache.
For stateful Java applications, session affinity is commonly configured at IBM HTTP Server, NGINX, F5, or application server plugin level.
Session vs Cookie vs JSESSIONID
| Component | Purpose | Stored In | Example |
|---|---|---|---|
| Session | Stores user-specific data | Application Server | User ID, role, login time |
| Cookie | Stores small client-side data | Browser | JSESSIONID cookie |
| JSESSIONID | Identifies the server-side session | Browser cookie or URL | ABC123XYZ789 |
Session Security Best Practices
Session security is very important because attackers may try to steal or misuse session identifiers.
- Use Secure flag so cookies are sent only over HTTPS.
- Use HttpOnly flag to reduce JavaScript-based cookie theft.
- Use SameSite attribute to reduce CSRF risk.
- Regenerate session ID after successful login.
- Configure proper session timeout.
- Invalidate session during logout.
- Avoid exposing JSESSIONID in URLs.
Recommended Cookie Example
Set-Cookie: JSESSIONID=ABC123XYZ789; Path=/; Secure; HttpOnly; SameSite=Lax
Common Session Issues
Middleware and DevOps teams commonly troubleshoot session-related issues in production environments.
| Issue | Possible Cause |
|---|---|
| User logged out unexpectedly | Session timeout or server restart |
| Session lost after login | Cookie not stored or wrong cookie path |
| Intermittent logout in cluster | Sticky session or replication issue |
| JSESSIONID not visible | Application not creating session |
| Cookie not sent over HTTPS | Secure flag or domain/path mismatch |
| Login loop | SSO, cookie, or reverse proxy issue |
Key Takeaways
- Authentication verifies identity.
- Sessions maintain user identity after login.
- Cookies store identifiers in the browser.
- JSESSIONID is the default session identifier for Java applications.
- Session affinity and replication are important in clustered environments.
- Cookie security flags such as Secure, HttpOnly, and SameSite improve session security.
- Session management is critical for WebSphere, JBoss, Tomcat, and enterprise applications.
What’s Next?
Part 3 – Stateful vs Stateless Applications
In the next article, we will understand the difference between stateful and stateless applications and why this concept is important for scaling enterprise applications, APIs, and cloud workloads.
Series: Authentication & Identity Security for Middleware, DevOps & Cloud Engineers
Author: Pradeep V
Blog:
MiddlewareBox.com
No comments:
Post a Comment