Implementing the timeout.resume.session parameter in WebSphere Portal

Technote (FAQ)


Question

When should the timeout.resume.session parameter be implemented in IBM® WebSphere® Portal, and what is the expected behavior when setting this value to "true"?

Answer

The timeout.resume.session parameter is not set as a custom property for the Resource Environment Provider WP ConfigService in the Integrated Solutions Console by default, which equates to the parameter being set to "false." Therefore, if an idle session timeout is experienced, a user will see the ErrorSessionTimeout screen and be forced to re-login. The login causes a new session to be created. This session is separate from the LTPA security token which allows for Single Sign-On.

The timeout.resume.session parameter should be set to "true" in cases where you do not wish for users to see the ErrorSessionTimeout screen and have to re-login to WebSphere Portal once the inactivity timeout for the WebSphere Portal application is exceeded. An example scenario would be if you were using an External Security Manager (ESM) and Trust Association Interceptor (TAI) to handle authentication for WebSphere Portal. You could take advantage of the security invalidation and timeout features of the ESM and TAI to control when the session gets invalidated (and thus when the user gets redirected to ESM's login page to re-login).

To illustrate further, review the behaviors in the following use cases. Environmental details include:

WP ConfigService is set to:

persistent.session.level = 2 (return to last visited page before session expired)
persistent.session.option =0 (user can't choose whether to resume session on login)

Session timeout (inactivity) is set to 2 minutes for WebSphere Portal.

Use Case #1 -- Default behavior of WebSphere Portal

-Login to WebSphere Portal with UserA. If you observe your session cookies in your browser, you'll notice that you have the following portal cookie set:
JSESSIONID=<value1>

-Let the browser sit idle for 5 minutes.

-Click on pageA. This should cause you to be redirected to the ErrorSessionTimeout screen, which states:

Your portal session has timed out because of no activity. Please start a new session at your portal Home.

-Re-login to WebSphere Portal with UserA. You should be redirected to PageA due to the current value in the persistent.session.level setting. You will notice that JSESSIONID has changed to <value2>.

Use Case #2 -- Using timeout.resume.session = true with WebSphere Portal

--Login to WebSphere Portal with UserA. If you observe your session cookies in your browser, you'll notice that you have the following portal cookie set:
JSESSIONID=<value1>

-Let the browser sit idle for 5 minutes.

-Click on pageA. This should cause you to actually view pageA. If you check the value of the JSESSIONID, you will notice that it has changed to <value2>. It is important to note that timeout.resume.session does NOT persist a session. It simply creates a new session without bothering the user to re-login. While it can save portlet states (Ex: minimized) and portlet modes (Ex: edit) between the sessions, it will not copy the contents of the old session to the new session.

Use Case #3 -- Using timeout.resume.session = false with WebSphere Portal and External Security Manager

For this case, the ESM inactivity timeout is set to 5 minutes.

-Login to WebSphere Portal via the ESM with UserA. If you observe your session cookies in your browser, you'll notice that you have the following portal cookie set (as well as any ESM-specific cookies):
JSESSIONID=<value1>

-Let the browser sit idle for 10 minutes.

-Click on pageA. This should cause you to be redirected to the login page of the ESM since you have set your ESM and Portal inactivity timeouts to be the same value (and your ESM would pick up the invalid session before it ever got to the portal server). However, once you re-log into the ESM, you may now see the WebSphere Portal session timeout screen, which is undesirable. This is a good reason to ensure that timeout.resume.session = true in WebSphere Portal environments where an ESM is utilized for authentication. If you have a valid reason for setting the value to false, then consider ensuring that the JSESSIONID is destroyed on the ESM login page (e.g. via javascript) to avoid an expired JSESSIONID being passed to WebSphere Portal.

Use Case #4 -- Using timeout.resume.session = true with WebSphere Portal and External Security Manager

-For this case, the ESM inactivity timeout is set to 5 minutes.

-Login to WebSphere Portal with UserA. If you observe your session cookies in your browser, you'll notice that you have the following portal cookie set (as well as any ESM-specific cookies):
JSESSIONID=<value1>

-Let the browser sit idle for 5 minutes.

-Click on pageA. This should cause you to actually view pageA. If you check the value of the JSESSIONID, you will notice that it has changed to <value2>.

-Let the browser sit idle for 10 minutes.

-Click on pageA. This should actually cause you to redirect to the ESM's login page. Upon logging in, you will get redirected to the desired portal page.

For further information on various session issues that can affect the behavior of WebSphere Portal or on how to collecting troubleshooting data to investigate such issues, reference the URLs in the "Related Information" section below.


Related information

Portlet window state not saved
Inconsistent Session Invalidation
Collecting Data: Session Management
Forced to login twice after WebSEAL session expires
Configuring user session persistence
Collecting Data: TAM WebSEAL integration
A simplified Chinese translation is available


Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

WebSphere Portal
Security

Software version:

6.0, 6.1, 7.0, 8.0

Operating system(s):

AIX, HP-UX, IBM i, Linux, Solaris, Windows

Software edition:

Enable, Extend, Server

Reference #:

1253578

Modified date:

2011-05-31

Translate my page

Machine Translation

Content navigation