The timeout.resume.session parameter is not included in the /shared/app/config/services/ 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. Note that the following environment was used for testing these use cases:

WebSphere Portal v5.1.0.2 with PK09525 installed

WebSphere Application Server v5.1.1.7 (includes PK03711)

WebSphere Business Integration Server Foundation v5.1.1.3 set to:

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

Session Inactivity timeout set to 5 minutes in WebSphere Administration console for WebSphere Portal application.

Filed in:
2 Comments To ' Implementing the timeout.resume.session parameter in WebSphere Portal '

Anonymous said...

You should point to the technote in which you got this info

Munish Gupta said...

The title pointed to the Tech Note.

Post a Comment