Write for OTN
Earn money and promote your technical skills by writing a technical article for Oracle Technology Network.
Learn more
Stay Connected
OTN Architect Community
OTN ArchBeat Blog Facebook Twitter YouTube Podcast Icon

Flexible Manipulation of Session Timeout for Oracle Identity Manager Web Applications

by Firdaus Fraz

Session timeout configuration for Oracle Identity Manager 11gR2PS1 using an Oracle WebLogic deployment plan

January 2014

Downloads
download-icon13-1Oracle Identity Manager

Session Timeout Configuration and its Importance

Session timeout, as its name implies, is the period of time after which the session object of a web application expires. The timeout period can be a fixed period (hard timeout) or an inactivity period (soft timeout) during which the user does not refresh or request a page. Once the session has reached the timeout, the user is required to re-authenticate to access the web application. Hard session timeout is a defined timeout period of the session ID irrespective of user activity; if the application has a hard session timeout of, say, nine hours, the user will be asked to re-authenticate after nine hours even if the session was used actively.

Hard and soft session timeout configuration is a security control measure that protects the user session from such security attacks as cross-site request forgery (CSRF), session fixation, etc.

There are few ways to configure hard and soft session timeout for applications. Here, we will discuss primarily the soft session timeout configuration for Oracle Identity Manager (OIM) version 11gR2PS1.

If an application is protected by an Access Management solution, the application session timeout must be configured through the Access Management tier.

For a standalone application (not using single sign-on), the (inactivity) session timeout configuration can be done through the application deployment descriptor files — web.xml orweblogic.xml (if the application is deployed in WebLogic Application Server) — or it can be configured using a WebLogic deployment plan.

This article discusses the session timeout configuration for OIM web applications using a WebLogic deployment plan.

Configuring Session Timeout for OIM Web Applications

OIM version 11gR2 PS1's session timeout configuration is defined in the web.xml files of its self-service and system admin web application.

You can change the session timeout by directly editing the web.xml file in both the self-service application archive (oracle.iam.console.identity.self-service.ear) and the sys admin application archive (oracle.iam.console.identity.sysadmin.ear) and then redeploying the applications.

However, since this approach requires manipulating the application archives, it is not recommended. Instead, we must perform the session timeout configuration using a WebLogic deployment plan.

The web.xml is available at the following path (and at a similar path for the sysadmin.ear):

oracle.iam.console.identity.self-service.ear\oracle.iam.console.identity.self-service.war\WEB-INF\

The session timeout configuration is as below. The value "15" refers to the number of minutes. The default value in sysadmin.ear is 35 minutes.

<session-config>
  <session-timeout>15</session-timeout>
</session-config>

Configuring Session Timeout with a WebLogic Deployment Plan

The session timeout for a J2EE application can be configured in its deployment descriptor files, web.xml or weblogic.xml. The configuration done in web.xml takes precedence over weblogic.xml.

WebLogic lets you define environment-dependent parameters in a deployment plan xml file, so you do not need to change the application archives if parameter values vary from development to test to production environment. You need only have different deployment plan xmls for each execution environment.

The configurations that have been defined in the deployment descriptor files of the application archives can be overridden via a WebLogic deployment plan.

The WebLogic deployment plan can be generated using the WebLogic tool weblogic.PlanGenerator or via the WebLogic admin console.

The configurations that you want to administer via the WebLogic deployment plan must be defined as variables in the deployment xml file. The variables can be configured through the Weblogic Administration Console.

The variable name for session timeout in web.xml is session-timeout (defined in number of minutes) and the variable name in weblogic.xml is timeout-secs (defined in number of seconds).

By default, if you generate a WebLogic deployment plan to configure session timeout, it assumes that timeout has been defined in weblogic.xml, and overwrites the configuration in weblogic.xml by the value that you provide for session timeout using the WebLogic Administration Console.

However, in our case, because the OIM application defines timeout at the J2EE application level (i.e., in web.xml files), we will customize the WebLogic deployment Plan.xml file to override the web.xml configuration. Since the configuration in web.xml is in minutes, the value that you provide through the WebLogic Administration Console for session timeout will be considered in minutes when you use this custom deployment plan.

The following steps guide you through the process of generating a WebLogic deployment plan (Plan.xml) that includes the session timeout variable configuration and of customizing the Plan.xml to override the session timeout configuration available in OIM application web.xml files.

The WebLogic deployment plan xml can be stored anywhere on the file system on the WebLogic installation machine.

Note: This is a custom solution and OIM patches/upgrades may overwrite the changes.

  1. Login to the WebLogic Administration Console (Figure 1).
  2. Go to Domain Structure > iam_domain > Deployments (where iam_domain is the name of the domain which hosts OIM).
  3. Click on the self service ear: oracle.iam.console.identity.self-service.ear
  4. At the bottom of the Overview tab, click Application Name.
fraz-oim-session-timeout-fig01
Figure 1: WebLogic Administration Console - Overview tab
  1. Click the Configuration tab (Figure 2).
  2. Under General, change the value in the Session Timeout box from the default 3600 seconds to the desired value.

    Important: The value you enter will be consumed as "number of minutes," even though the field label says "number of seconds" because we are overriding web.xml.
fraz-oim-session-timeout-fig02
Figure 2: Setting the Session Timeout value
  1. Click Save. The deployment plan is automatically generated.
  2. Click the Activate Changes button in the Change Center (top left portion of the Weblogic Administration Console, as seen in Figure 1).
fraz-oim-session-timeout-fig03
Figure 3: Deployment plan xml path: /app/Middleware/Oracle_IDM1/server/apps/Plan.xml
  1. Edit the Plan.xml and add variable assignment for web.xml. This change must be done manually, using any text or xml editor.

    Note: The variable name will be different in your deployment.

    <module-descriptor external="false">
      <root-element>web-app</root- element>
        <uri>WEB-INF/web.xml</uri>
          <variable-assignment>
            <name>SessionDescriptor_timeoutSecs_13732841600120</name>
          <xpath>/web-app/session-config/session-timeout</xpath>
        <operation>replace</operation>
      </variable-assignment>
    </module-descriptor>
    
  2. Click Save.
  3. To redeploy the OIM self-service and sysadmin applications, access the Deployments page (see steps 1 and 2, above), click Lock & Edit in the Change Center, choose the desired application, then click Update (Figure 4).

    Make sure the application is deployed with the deployment plan generated in previous steps.
fraz-oim-session-timeout-fig04
Figure 4: Selecting and redeploying the OIM self-service and sysadmin applications
  1. Repeat same steps for the sysadmin ear file: oracle.iam.console.identity.sysadmin.ear

About the Author

Firdaus Fraz is Principal Solutions Architect with the Oracle Fusion Middleware Identity Management A-Team. In this role she works with IDM customers and partners world wide to provide guidance on implementation best practices, architecture, use-case design, and troubleshooting.
Blog LinkedIn