This article talks about EBS session management and in particular, how user logins and sessions are managed using database tables APPLSYS.FND_LOGINS and ICX.ICX_SESSIONS. Specifics in this article apply to EBS R12.1.1.
Let us see what happens when a user, say OPERATIONS, brings up EBS login page, in a browser, say IE8, for the first time.
1. EBS server generates a new session, which is not yet stored in the database, and
encrypted version of the session id is passed back to the browser in a cookie with key-name JSESSIONID. HTTP response header looks something like,
Set-Cookie:
JSESSIONID=a7eb1fe1f559b459516815325503b8a1d6e0b575789f1351f1b687abe32bb383.e34Lbh8OahqOai0MbN0La3mOb3r0; path=/OA_HTML
Browser uses this JSESSIONID for all further interactions with EBS server. You can easily see this, if you monitor HTTP traffic between your machine and the EBS server.
2. When OPERATIONS user provides the credentials, say OPERATIONS/welcome, browser
sends a POST request to EBS server along with cookie information which it got from the server in the first place. First and foremost, an entry is created in FND_LOGINS table. You can fire
following SQL queries to find out the entry made in FND_LOGINS table.
SELECT USER_ID, USER_NAME FROM FND_USER WHERE USER_NAME = 'OPERATIONS';
gives USER_ID of user 'OPERATIONS'.
FND_LOGINS table has USER_ID column. Now you can fire following query with the USER_ID you obtained from the first query
SELECT * FROM FND_LOGINS WHERE USER_ID = 1318 ORDER BY START_TIME DESC;
Along with USER_ID which identifies the user, FND_LOGINS table has following important columns like LOGIN_ID, START_TIME and END_TIME. LOGIN_ID is auto generated and unique. There could be many LOGIN_IDs associated with a single USER_ID. Even if same user logs onto EBS server from the same machine using two browser instances, two rows in FND_LOGINS table would get generated, each with different LOGIN_ID.START_TIME is the time when user logs in and END_TIME is updated only if user explicitly logs out from the application.
Next an entry is made into ICX_SESSIONS table. ICX_SESSIONS and FND_LOGINS tables are are correlated by the column LOGIN_ID. ICX_SESSIONS has session id whose encrypted version was sent out by EBS server in the first place when user brings up EBS login page.
When user logs out from the application, with JSESSIONID passed as part of the cookie, EBS figures out from the corresponding row in ICX_SESSIONS table, gets LOGIN_ID, gets corresponding entry from FND_LOGINS table and updates END_TIME and which basically means session has been terminated.
3. Say user OPERATIONS explicitly logs out from the application and again brings up login page,without clearing browser session cookie cache, which is what users normally do, broswer does send EBS server JSESSIONID, it already has, but EBS figures out session associated with this JSESSIONID is terminated and generates a new session id and sequence continues as discussed in 2 above.
4. Having explained this simple use case, let us discuss about a scenario, where multiple logins are made from the same machine and same browser. Say you open two tabs in IE8 and bring up EBS login page in both of them and login in one tab using OPERATIONS/welcome and in second using SYSADMIN/welcome. Note here that, as browser session cache is shared by these two tabs, same JSESSIONID is used by both browers. So moment second user, SYSADMIN/welcome logs in, EBS server logs out OPERATIONS user from the system. See contents of table FND_LOGINS after both users have logged in. For the second user SYSADMIN (with USER_ID 0) START_TIME is same as END_TIME for user OPERATIONS (with USER_ID 1318).
LOGIN_ID USER_ID START_TIME END_TIME
---------------------------------------------------------------
5514220 0 20-SEP-2010 22:48:11 (null)
5514219 1318 20-SEP-2010 22:47:59 20-SEP-2010 22:48:11
---------------------------------------------------------------
5. Let us now take a look at the parameters in EBS which govern session timeout.
'ICX:Session Timeout' profile option determines the length of time (in minutes) of inactivity in a user's session before the session is disabled. Note that disabled does not mean terminated or killed. The user is provided the opportunity to re-authenticate and re-enable their timed-out session. If the re-authentication is successful, the disabled session is re-enabled and no work is lost. Otherwise, the session is terminated without saving pending work.
'ICX: Limit Time' profile option defines the maximum connection time (in hours) for a connection regardless of user activity. If 'ICX:Session Timeout' is set to NULL, then the session will last only as long as 'ICX: Limit Time', regardless of user activity.
On our R12.1.1 installation these two profile options had values 30 and 999 respectively. Recommended value are 30 minutes and 4 hours respectively. Table ICX_SESSION has two columns TIME_OUT and LIMIT_TIME where these values are stored for every session.
6. A note about IE8.
In order for forms based applications to work with IE8 you need to disable a security setting related to Cross Site Scripting (XSS). Firstly you need to add the EBS application server to trusted sites within IE as we definitely do want the IE8 XSS filter active for general Internet browsing.
In IE8 Select Tools->Internet Options->Security(tab)->Trusted Sites
Click Sites and type in the hostname of the server running R12 and add the website to the list of trusted sites.
Still in the Security tab click the custom level button and find out the setting 'Enable XSS filter' and set it its value to 'Disable'