Extending_the_WebSphere_Portal_Session_Timeout

This article walks you through the steps to extend the WebSphere Portal Session Timeout when the security is enabled.This article assumes that the security is enabled on portal. If not, the below link has useful information on enabling the security./infocenter/wpdoc/v6r0/index.jsp?topic=/com.ibm.wp.zos.doc /wpf/cu_cdsec_zos.htmlFollowing is the environment where the portal session timeout has been extended to 720 minutes (12 hours). The default value is 30 min.WebSphere Portal : IBM WebSphere Portal for Multiplatforms Version 5.1.0.3WAS : IBM WebSphere Process Server Version 6.0.1.0Database : DB2 8.2LDAP : Tivoli Directory ServerStandalone or Clustered : StandaloneProblem Description: In the default scenario, when the session times out, the user needs to relogin again to the portal and the user needs to traverse through all the pages to reach the desired page. This is a time consuming thing and irritates the user to use the portal.Solution: In this article, I will be showing the steps to extend the portal session timeout and also how the portal can be configured to get the same page back to the user after relogin.Here are the steps to configure portal to achieve the solution:Step 1) Setting the session timeout at WebContainer levelOpen the websphere admin console after starting the servers and select the WebSphere Portal server.∙Click on the ‘Session Management’ link under the ‘WebContainer Settings’scetion as shown below.∙Set the Session Timeout to the desired value (in min) as shown below. The default in 30 min.Here, I am not discussing about any other setting as they are not related to this article.Note:1)When you configure session management at the Web container level, all applications and the respective Web modules in the Web container normally inherit that configuration, setting up a basic default configuration for the applications and Web modules below it. However, you can set up different configurations individually for specific applications and Web modules that vary from the Web container default. These different configurations override the default for these applications and Web modules only.2) When you overwrite the default session management settings on the application level, all the Web modules below that application inherit this new setting unless they too are set to overwrite these settings.Step 2) Now, lets make the portal configuration for ‘Persistent session state’. This feature is also called as ‘Session Hibernation’. I would like to give you little background about this feature.With the persistent session state feature, portal users can resume and continue a previously interrupted working session at the same state where they left the session. When the user logs out or the session times out, the portal stores the current navigational state into the database. The administrator can give users the option to resume the navigational state of their last session when logging in again. When the user chooses to resume the last session, the navigational state stored previously is restored, and the user can continue working where the user stopped before.Following are the session settings stored by portal when the user logs out:After a user logs out or the session times out, the portal stores the complete navigational state into the database. This includes the following navigational state information: ∙Portlet states:o Normalo Minimizedo Maximized∙Portlet modes:o configo edit_defaultso edito viewo helpPage selection:o The last page that was active before the user logged out.User needs to choose the check box ‘Resume last session’ during login time, if the user wants to resume the last session. Otherwise, the last session won’t be resumed.To provide this feature to the user, administrator has to configure the portal as explained below. All of the below settings needs to set in the‘ConfigService.properties’ file and this file can be found under the directory<Portal_Root>/config/services.1.persistent.session.optionThis property determines whether the login portlet (or the login screen respectively) displays a check box that enables the user to decide whether to resume the session or not. Administrator needs to set this property‘persistent.session.option’ in Configuration Service file as shown below. persistent.session.option = 0This means that the user does not have the choice to resume the last session or not. persistent.session.option = 1This means that at login the user is presented with the option to resume the session in the navigational state of the last session.The default setting is 0, that is, users have no option to resume their last session.Note: If you give users the resume option, you should set the session resume level to 1 or higher. Otherwise the persistent.session.option property has no effect.2.persistent.session.levelThis property determines which navigational state information should be restored when resuming the session. The administrator can choose from three predefined levels. Portal administrators can configure the session resume level by setting the property persistent.session.level in Configuration Service as shown below.persistent.session.level = 0This means no persistent session state at all applies to the user session. Duringlogout or session timeout no navigational state information is stored into thedatabase. After a login no navigational state is restored.persistent.session.level = 1The portlet states and the portlet modes are stored in the database and are restored to the user session when the respective user logs in again.. For example, allmaximized portlets are still maximized. However, no information about the lastactive page is stored. This means that the user starts with the default page after alogin.persistent.session.level = 2This is the maximum level of persistent session state. Using this level, thecomplete navigational state information is stored. This includes portlet-specificnavigational state (portlet states, portlet modes, and render parameters) as well as page selection information mentioned above. In contrast to persistent session level1 the session now starts with the last page that was active before the user loggedout.The default setting is 0, that is, no persistent session state is stored or restored.The same above is shown below in tabular format for easy understanding:3.timeout.resume.sessionThis property determines whether resuming the session after a session timeout requires user authentication. The default value is false. If this property is set to false and the user tries to continue working after a session timeout, the portal shows an error message stating that the session has timed out and the user has to log in again. If you set this property to true, the portal ignores the session timeout and does not show the error message. The user can resume the previous session without authentication and continue to work. In both cases the previous session is resumed according to the setting of the persisted.session.level property described above.Since the user needs not to relogin again, you set this to ‘true’ as shown below. timeout.resume.session=trueStep 3) Configuring the Lightweight Third Party Authentication mechanismYou must configure Lightweight Third Party Authentication (LTPA) when you set up security for the first time. LTPA is the default authentication mechanism for WebSphere Application Server.Enter a positive integer value (720 min as shown below) in the Timeout field. This time out value refers to how long an LTPA token is valid in minutes. The token contains this expiration time so that any server that receives the token can verify that the token is valid before proceeding further.When the token expires, the user is prompted to log in. The default value is 30 minutes.1.Click Security > Global security.2.Under Authentication, click Authentication mechanisms > LTPA.3.Enter the value 720 in Timeout field.With this, the configuration part is completed and now restart both WebSphere and Portal Servers to have the chages reflected.Open the portal and navigate to your desired page and leave it idle for 1 or 2 hours and see. You shouldn’t loose your session. The session should last for 12 hours as per the configuration.。