Problem StatementWebSphere Portal provides many ways to configure a variety of security scenarios. Sometime it becomes necessary to customize or extend the default product capabilities for login, logout, or session handling.
Session management in portal is handled optimally by portal engine. In case of Anonymous user access, portal can optionally create sessions for user access. In case of registered users, portal creates user session after user is successfully authenticated.
This article addresses problem when user logs in at once from multiple places. For example consider these scenarios:-
In portal, session is tracked by cookie using JSessionID. If you open a new window from existing browser window then cookie is propagated so portal maintains same session however opening a different browser instance does not propagate cookie so it creates a new session at portal end. It means user can establish two sessions at the same time from one machine.
With the increased usage of smart mobile devices, user logging in at once from multiple places is becoming a commonplace.
These types of scenarios bring data inconsistency issues that should be thought through in the architecture. Consider example of banking portal where multiple sessions per user needs to be handled efficiently.
This article addresses this problem efficiently in context of both the versions of portal, WebSphere Portal Server V6.0 and WebSphere Portal Server V6.1.
Terms to Note:
Throughout the article I would be using some terms like ‘first user’ or ‘second user’, these users are defined as channel specific user.
The term ‘first user’ means user ‘x’ logging in using 1 channel.
The term ‘second user’ means user ‘x’ logging in using 2nd channel.
They refer to ‘same’ user ‘x’.
Solution OverviewThis article will talk about how to control multiple sessions of same user in portal implementations. In portal we cannot get hold of logged-in user sessions due to security constraints. When same user logs in from multiple places we cannot automatically logout every other logged-in user from portal but we can force log-out user upon duplicate session detection writing custom logic. [Force Log-out]Redirect user to a blank page with Log-out button only.
There are two approaches to resolve multiple sessions of same user:-
- Allow second user to log-in whereas force first user to log-out session from portal.
- Force second user to log-out as first user has already logged-in.
This article will discuss solution to both the solution approaches as stated above. It will also discuss pros and cons of both the approaches in detail.
Approach – 1: Force first user to log-out session from portal
SolutionIn this approach we will allow second user to successfully log-in to the system, whereas we force log-out first user session from the server.
Figure – 1, User Login Flow
StepsWe track user session in server using database and in-memory cache module. The reason for choosing database is that it is common across all cluster members. Database module is referred during login process and cache module is referred on every other request then login per user session.
Algorithm is executed after user has successfully logged-in during portal post login module.
In Portal V6.0, we may need to write post login module where we will track user session. Please refer article HYPERLINK "http://www-01.ibm.com/support/docview.wss?uid=swg21263681&aid=3" http://www-01.ibm.com/support/docview.wss?uid=swg21263681&aid=3 for more details.
In Portal V6.1, we write ExplicitLoginFilter to write post login module. Please refer article HYPERLINK "http://www.ibm.com/developerworks/websphere/library/techarticles/0905_buchwald/0905_buchwald.html" http://www.ibm.com/developerworks/websphere/library/techarticles/0905_buchwald/0905_buchwald.html for more details.
We have used Database to track user entity, we can also use User registry configured with Portal server to track user logged-in status. DB table structure is like this:-
| CustomerID | VarChar
| Node IP | VarChar
In case of cluster, node ip will be server name. Database can help us detect duplicate sessions, but it cannot help us log-out user.
As soon as we detect second user has logged in we update in-memory cache and send log-out for first user to all servers in cluster. User request flow and Remote log-out module is explained below in flow-chart. We updated in-memory cache module to reflect new session has been established for user ‘x’.
Whenever first user accesses the system next time, in-memory cache is checked to validate session status, if his session is not valid then we log-out this user from portal server.
Figure -2, User Normal Request Flow
Figure -3, Remote Log-out Flow
Implementation DetailsWe will send remote logout request to all cluster members in cluster. Remote Log-out request will look like:- HYPERLINK "http://
/action/logout.action?customerid=&sessionid=/action/logout.action?customerid=&sessionid=
Remote Log-out request will be server-to-server forward and no redirect.
Remote Log-out Module is implemented as servlet. This module should be deployed on all the nodes in cluster.
When user accesses the system whether user is logged-in or not, its status is checked against cache, all this logic should be implemented in Servlet Filter on top of portal servlet. The reason being, the Filter will always execute on each request.
We used database to check whether user has logged in or not, implementers can use LDAP or portal configured repository to maintain this status. Fields and attributes are required as specified above.
While Logging-out first user from portal we are showing page with warning message and when the user will click on Ok, he is logged-out. This behavior can be overridden to directly log-out user without showing warning message.
In-Memory Cache is implemented using Dyna-Cache. Key in cache is userId whereas its value is sessionID and NodeIP.
In-Memory Cache is not shared across nodes in cluster.
On every request cache entry is touched so as to keep its TTL beyond session idle time-out.
Session Invalidation Listener should be implemented on portal server to clean in-memory state from cache on session invalidation.
We are not using Timestamp column in DB Table but has been kept there for future requirements.
Performance Implications
On every Login request we have now introduced new hob i.e. DB for processing.
In-memory cache is referred on every request per session.
If user closes the browser window then its session is not invalidated from in-memory cache. It will be maintained in memory for session idle time-out, after that it is automatically evicted out from cache.
Limitation
Session Affinity has to be enabled for this implementation. Session Affinity is enabled at “IHS” level, which means request for same session will land on node which establishes the session.
Approach – 2: Disallow second user to log-in
Solution
In this approach we will not allow second user to log-in to the system, as first user has logged into the system.
Figure – 4 User Login Flow
Algorithm
We track user session in server using Database module.
Algorithm is executed after user has successfully logged-in during portal post login module.
As soon as we detect second user has logged in we check DB for its status and if first user has already logged-in and its time is less then session idle time-out then we dis-allow this user from logging in. We will redirect user to a blank page with Log-out button from portal post login module.
If user entry exist in DB then timestamp is checked for session idle time-out, if it is beyond session idle time-out then user is allowed to log-in.
When user accesses the system whether user is logged-in or not it status is checked against DB, all this logic should be implemented in Servlet Filter on top of portal servlet. The reason being is Filter will always execute on each request.
We used database to check whether user has logged in or not, we can also use LDAP or portal configured repository to maintain this status. Fields and attributes required are specified above.
On every request DB Timestamp entry is touched so as to keep its TTL beyond session idle time-out.
Session Invalidation Listener should be implemented on portal server to clean Timestamp, sessionID state from cache on session invalidation.
Algorithm of updating DB entry is implemented after user has successfully logged-in. It should be implemented in custom Portal login/logout extension.
DB table details are as under:-
| CustomerID | VarChar
SessionID | VarChar
Performance ImplicationsOn every request we have now introduced new hob i.e. DB for processing. Database user record is processed on each request. Timestamp is updated with new interaction time in DB.
LimitationIf user closes the browser window then its Timestamp is not invalidated in DB. It will be maintained in DB for session idle time-out, which essentially means same user cannot login for period less then session idle time-out.