ShowTable of Contents
WebSphere Portal provides many ways to configure a variety of security scenarios. Sometime it becomes necessary to customize or extend the default product capabilities for log in, log out, or session handling.
Session management in WebSphere Portal is handled optimally by the portal engine. In the case of anonymous user access, WebSphere Portal can optionally create sessions for user access. In the case of registered users, WebSphere Portal creates a user session after the user is successfully authenticated.
In this article, we address the problem in which a user logs in at the same time from multiple places. For example, in WebSphere Portal, a session is tracked via a cookie using JSessionID. If you open a new window from an existing browser window, the cookie is propagated, so WebSphere Portal maintains the same session.
However, opening a different browser instance does not propagate the cookie, so it creates a new session at the WebSphere Portal end. This means that a user can establish two sessions at the same time from one machine.
In addition, with the increased use of smart mobile devices, a user logging in at the same time from multiple places is becoming commonplace.
These types of scenarios cause data inconsistency issues that should be addressed in the architecture; for example, consider a banking portal in which multiple sessions per user needs to be handled efficiently.
Throughout the article we use the terms “first user” and “second user”. These users are defined as channel specific users as follows:
- “First user” means that user ‘x’ logs in using the first channel.
- "Second user” means that user ‘x’ logs in using the second channel.
They refer to the “same” user ‘x’.
In WebSphere Portal we cannot control logged-in user sessions due to security constraints. When the same user logs in from multiple places, we cannot automatically log out every other already logged-in users with the same userid.
We can, however, force a user to log out by writing a custom logic upon duplicate session detection. For example, when the same user logs in with a common userid from some other place, we can redirect the user to a blank page with a Log-out button only, thereby creating a “forced log-out”.
This article discusses the following two approaches to resolve multiple sessions by the same user, including the pros and cons of both:
- Allow a second user with same userid to log in while forcing the first user to log out of their WebSphere Portal session.
- Force the second user to log out as the first user with same userid has already logged in.
In this approach we allow a second user to log into the system successfully while forcing a log-out of the first user session from the server. Figure 1 shows the flow of a user log-in, where we track user sessions on the server, using a database
and an in-memory cache module.
The reason for using this database (“DB” in the figure) is that it is common across all cluster members. A database module is referred only for the first time the user logs in, whereas a cache module is referred on every other request per user session.
Figure 1. User log-in flow
The steps in this flow are as follows:
- An algorithm is executed after the user has successfully logged in during the WebSphere Portal post-log-in module:
2. Not only do we use the database to track the user identity, but we can also use the User registry configured with WebSphere Portal server to track a user's logged-in status.
The database table structure looks like this:
NOTE: In the case of a cluster, the node IP will be the server name. Also, the Database can help us detect duplicate sessions, but it cannot help us log out the user.
Figure 2. Normal user request flow
Figure 3. Remote log-out flow
3. As soon as we detect that a second user has logged in, we update the in-memory cache and send a log-out to all servers in the cluster for the first user. The user request flow and the remote log-out module flow are shown below in figures 2 and 3, respectively.
4. We update the in-memory cache module to reflect that a new session has been established for user ‘x’.
5. The next time the first user accesses the system, the in-memory cache is checked to validate the session status; if his session is not valid, then we log-out this user from the WebSphere Portal server.
Here are the detailed steps to implement this approach:
- We send a remote log-out request to all members of the cluster, which looks like this:
The remote log-out request is server-to-server forward with no redirect. The remote log-out module is implemented as a servlet. This module should be deployed on all the nodes in cluster.
When a user accesses the system, the status of the user (whether he/she is logged in) is checked against the cache.
NOTE: This logic should be implemented in a servlet filter on top of a WebSphere Portal servlet, so that the filter will always execute upon each request.
2. We used a database to check whether a user has logged in; however, implementers can use LDAP or the WebSphere Portal-configured repository to maintain this status. Fields and attributes are as specified in the data structure table above in Step 2.
3. While logging out the first user from WebSphere Portal, we show a page with a warning message, and when the user clicks OK, he/she is logged out. (This behavior can be overridden, so that a user can be logged out directly without showing the warning message.)
4. The in-memory cache is implemented using WAS DynaCache. The key in the cache is userId, and its value is sessionID, NodeIP. Also note that:
- In-memory cache is not shared across nodes in a cluster.
- On every request, the cache entry is touched so as to keep its TTL (Time to Live) longer than the session idle time-out.
5. A Session Invalidation Listener should be implemented on the WebSphere Portal server to clean in-memory states from the cache upon session invalidation.
NOTE: We are not using the Timestamp column in the database table structure (from Step 2 above), but it's kept there for future requirements.
- On every log-in request, we have now introduced a new hop (the database) in the process.
- In-memory cache is referred on every request per session.
- If users close the browser window, their session is not invalidated from the in-memory cache. Instead, it will be maintained in memory for session idle time-out, after which it is automatically removed from the cache.
Session Affinity must be enabled for this implementation. This is done at the IBM HTTP Server (IHS) level, which means that a request for the same session will land on the node that establishes the session.
In this approach we do not allow a second user to log into the system, when a first user has already logged in. Figure 4 shows the user log-in flow chart.
Figure 4. User log-in flow
Here we track user sessions on the server using the database module, and the algorithm is executed after a user has successfully logged in during the WebSphere Portal post-log-in module.
- As soon as we detect that a second user is attempting to log in, we check the database for his status. If the first user has already logged in and his time is less than the session idle time-out, then we disallow the second user from logging in.
- This user is redirected to a blank page with a Log-out button from the WebSphere Portal post-log-in module.
- If a user entry exists in the database, then the timestamp is checked for session idle time-out; if it is beyond the session idle time-out, then the user is allowed to log in.
- When a user accesses the system, whether logged-in or not, his status is checked against the database. (This logic should be implemented in the servlet filter on top of a WebSphere Portal servlet so that the filter will always execute upon each request.)
- We used the database to check whether a user has logged in, but we can also use LDAP or a WebSphere Portal-configured repository to maintain this status. (Again, the required fields and attributes are specified above.)
- On every request, the Database Timestamp entry is touched so as to keep its TTL beyond the session idle time-out.
- The Session Invalidation Listener should be implemented on the WebSphere Portal server to clean Timestamp and sessionID states from the cache upon session invalidation.
- The algorithm of updating the database entry is implemented after a user has successfully logged in. It should be implemented in a custom WebSphere Portal login/logout extension.
The database table details are as follows:
On every request we have now introduced a new hop, that is, the database, for processing. The database user record is processed on each request, and the Timestamp is updated with the new interaction time in the database.
If a user closes the browser window, then the user's log-in timestamp that was set at the time of user log-in is not invalidated in the database. Instead, it will be maintained in the database until session idle time-out, which essentially means that same user cannot log in for a period less than the session idle time-out.
This article has described two approaches to controlling multiple sessions from the same user in WebSphere Portal server implementations: ( 1) Allow a second user to log in while logging out the first user session, and (2) Restrict a second user from logging in when a first user session has already logged in.
IBM WebSphere Portal information center:
developerWorks® WebSphere Portal product page:
WebSphere Portal forum and community:
About the author
is an IBM Certified IT Specialist working with IBM Lotus Lab Services, India Software Labs, based in Gurgaon, India. He specializes in Enterprise Portal Solutions, Web 2.0 technology strategies, and Enterprise Collaboration platforms, and for the past six years has delivered Enterprise Portal and Collaboration solutions for customers across India and Southeast Asia. Before his current role, Nitin served as the Component lead in the Product Development Lab. He can be reached at email@example.com