# Setting the session timeout for SOA Suite Consoles

Author: Robin Zimmermann
Date: November 2006

## Introduction

All of the consoles and controls for Oracle SOA Suite 10.1.3.1.0 can be accessed using a single sign-on account. (By default, the account name is oc4jadmin.) This is useful because you only have to remember one username and password, and once you logon to any screen, you can then access all other screens without having to logon again.

Typically for such systems, there is a session timeout mechanism -- for obvious security reasons. However in non-production environments, constantly having to logon after your session timed out can become tedious. This paper will show you how to change the session timeout to any length of time that you desire.

## Caveats

The intent of this paper is to show you how to extend the session timeout so you don't have to logon repeatedly for non-production environments. In production environments, or other environments where you care about security, you should set your session timeout appropriately.

## Conventions

### Paths

When you see the following variable, replace it with the corresponding value for your environment.

- Variable: ${SOA_HOME}
  Description: The location you installed SOA Suite to.
  Example: If ${SOA_HOME} = C:\product\10.1.3.1\OracleAS_1 then ${SOA_HOME}\opmn\bin would be C:\product\10.1.3.1\OracleAS_1\opmn\bin.

## Explanation of JSSO

The single sign-on mechanism used by the various consoles in this release of Oracle Application Server is referred to as JSSO (Java Single Sign-On). Applications may or may not be protected by JSSO. An application is defined as some web application that you've deployed. The various SOA Suite Controls are also applications, such as BPEL Control, ESB Control, etc. If an application is protected by JSSO then it's session timeout is controlled by JSSO. Also, if you logon to a JSSO-protected application, then you are automatically authenticated for all JSSO applications and don't have to logon again. If the session expires, it expires for all of those applications.

Applications not protected by JSSO each have their own independent authentication, so you will have to logon to each one separately. They also have a separate timeout. So one application may timeout after 5 minutes, another after 30 minutes. (Applications protected by JSSO can still have separate timeouts for their state, however, such as for a shopping cart.)

The situation is different depending on how you installed Oracle SOA Suite:

- Basic Install
  JSSO was automatically configured for you. The various component controls and consoles -- or, technically speaking, applications -- were also configured to be JSSO-protected:
  - BPEL Control
  - ESB Control
  - OWSM Control
  - Rule Author
  - Application Server Control
  If you change the session timeout for JSSO, it will affect all applications protected by JSSO.
- Advanced installation
  JSSO was not configured. Each application has its own session timeout independent of all others. Changing the timeout for one application doesn't affect any others. To use JSSO, you have to configure it manully (beyond the scope of this paper).

This paper shows you how to change the session timeout for both JSSO-protected applications and those that are not protected by JSSO.
Appendix B shows how you can view the status of JSSO, it's timeout setting, and what applications are protected by JSSO.

## Steps for JSSO-Protected Applications

This section will show you how to modify the session timeout for JSSO. If you have applications not protected by JSSO, the steps for those are shown in the next section.

The default session timeout is 30 minutes (1800 seconds). Once you logon, your session will expire after this time. If you did a basic installation, then modifying this timeout will affect BPEL Control, ESB Control, Rules Author, OWSM Control, and Application Server Control.

You can change this setting using the AS Control GUI, or directly in the XML configuration files. Both methods are shown, below. Pick your preferred method and follow those steps.

### Changing JSSO Session Timeout Using AS Control

1. | Ensure that you have a working version of Oracle SOA Suite 10.1.3.1.0 installed. The server should be running. See Appendix A if you're not sure how to do this.
2. | Using a browser, open AS Control: http://localhost:8888/em
3. | Scroll to the bottom of the page and click the Java SSO Configuration link.
4. | The Session Timeout (secs) field shows the current timeout. Change it to your desired setting. e.g. 43200 seconds would be 12 hours.
5. | Click Apply.
6. | Click the Restart link to restart the server. Your settings will then be in effect. Note: The server will restart which could take several minutes. During that time, you won't be able to access any screens. You also won't be able to tell when the server has restarted and you can access the screen again. You can watch the CPU of you machine; it will be high while the server is starting -- once it drops back to normal levels you can try accessing the server again. A more sure way is to check the status every 30 seconds or so. See Appendix A if you're not sure how to do this.

### Changing JSSO Session Timeout Using XML Configuration Files

1. | Ensure that you have a working version of Oracle SOA Suite 10.1.3.1.0 installed. If it is running, then stop it. See Appendix A if you're not sure how to do this.
2. | Using a text editor, open ${SOA_HOME}\j2ee\home\config\jazn.xml. This is where the session timeout is specified. You may wish to make a backup of this file, just to be safe.
3. | Within the <jazn> element, modify this property, or add it if it doesn't exist: <!-- Session timeout, specified in seconds. --> <property name="custom.sso.session.timeout" value="43200"/> In this example, 43200 seconds is used, which equates to 12 hours.
4. | Start the server when you are ready, and the timeout will be in effect. See Appendix A if you're not sure how to do this. See Appendix B for steps to verify the timeout in effect.

## Steps for Applications Not Protected by JSSO

For applications that are not JSSO-protected, you need to set their timeout values separately. Appendix B shows how you can determine which applications are protected by JSSO. For JSSO-protected applications, changing these timeouts won't have an affect because their session timeouts are being overridden by the JSSO timeout setting.

1. | The timeout setting for applications are specified in the following file for each application: ${SOA_HOME}\j2ee\home\applications\APPLICATION\WEB_MODULE\WEB-INF\web.xml
where: | APPLICATION | = the application name
| WEB_MODULE | = the web module name
Here is a list of application and web module names for some of the default SOA Suite applications (also included is the client GUI for the SOA OrderBooking Demo):
Application | Application Name | Web Module Name
--- | --- | ---
Application Server Control | ascontrol | ascontrol
BPEL Control | orabpel | console
ESB Control | esb-rt | provider-war
Rule Author | ruleauthor | ruleauthor
OWSM Control | ccore | ccore
Human Worklist Application | hw_services | worklistapp
SOA OrderBooking Demo Client | SOADEMO | soaui
For example, if you wanted to change the timeout for the Human Worklist application, you would need to modify: ${SOA_HOME}\j2ee\home\applications\hw_services\worklistapp\WEB-INF\web.xml Remember that if any of those applications are protected by JSSO, then modifying their individual timeouts won't have any effect. If you did a basic installation, then you only need to worry about the Human Worklist Application and the SOA OrderBooking Demo client (if you have it installed) as the others are protected by JSSO.
2. | From the table in Step 1, pick the application whose timeout you want to modify. Using a text editor, open the web.xml file for that application. (Step 1 shows you how to determine the web.xml file.) For example, if you wanted to modify the timeout for the SOA OrderBooking client screens, you would open: ${SOA_HOME}\j2ee\home\applications\SOADEMO\soaui\WEB-INF\web.xml
3. | Within the <web-app> element, add the following:
      <!-- Activity timeout, specified in minutes. -1 = never expire. -->
      <session-config>
        <session-timeout>-1</session-timeout>
      </session-config>
Specify the time in minutes, or put -1 which means it will never expire due to inactivity. (Make sure the parent tag is <web-app>. You don't want to put your changes inside one of the other child elements of <web-app>.)
4. | The current deployment of this application needs to be removed, so that upon startup, the application server redploys this app and consumes this new setting. Rename: ${SOA_HOME}\j2ee\home\application-deployments\APPLICATION\WEB_MODULE\orion-web.xml to: orion-web_ORIGINAL.xml. (Remember to replace APPLICATION and WEB_MODULE with the appropriate values.) This effectively "deletes" the file, but preserves it in case you want to restore back to it. All that matters is that upon startup, the application server sees that the file orion-web.xml does not exist, and redploys it.
5. | Repeat Steps 2 - 4 for each application whose timeout you want to set.
6. | Start the SOA Suite server. See Appendix A if you're not sure how to do this. Your new settings are now in effect.

### Verification

You can check and see that the various orion-web.xml files have been created. (You can open them, but they won't contain any reference to <session-config>.)

Since the orion-web.xml files don't contain references to the session settings, it can be hard to confidence that your settings are in effect. As a test, the first time you follow these steps, change your session timeout to 1 minute. Once the server is restarted, logon to your application, wait for a minute. Then try to interact with the application. You should be prompted to logon again.

Don't forget to change the timeout back to what you really want.

## Miscellaneous

If you redeploy and application you may have to reset the timeout. For example, if you re-install the SOA OrderBooking Demo client, then you would have to set the timeout again, as your redeployment would've set the timeout back to the default value. Of course, you could also just set the timeout within the .war file of the application you are deploying to whatever value you like. Then simply deploying it will set the timeout to the correct value.

## Appendix A - Starting and stopping Oracle SOA Suite

There are multiple ways to start and stop Oracle SOA Suite 10.1.3.1.0. Here is a recommended way:

1. Open a command window (Start > Run > cmd on Windows).
2. Change directory to ${SOA_HOME}\opmn\bin.
3. Type opmnctl startall to start SOA Suite.
4. Type opmnctl stopall to stop SOA Suite.
5. If you're not sure if it's running or not, type opmnctl status. Here is some example output:

            Processes in Instance: soa101310.myhost
            ---------------------------------+--------------------+---------+---------
            ias-component                    | process-type       |     pid | status
            ---------------------------------+--------------------+---------+---------
            OC4JGroup:default_group          | OC4J:home          |    2576 | Init
            ASG                              | ASG                |     N/A | Down

   If the status says "Init" (highlighted in red in the example) then the server is still starting. It will say "Alive" once the server has fully started.

## Appendix B - Checking JSSO Status

Configuring JSSO is beyond the scope of this paper, but you can see what the JSSO session timeout is and what applications are protected by JSSO.

1. | Using a browser, open AS Control: http://localhost:8888/em
2. | Scroll to the bottom of the page and click the Java SSO Configuration link.
3. | The Session Timeout (secs) field shows the current timeout.
4. | Select the Participating Applications sub-tab. A list of applications is shown, and the Java SSO Enabled column indications if the application is protected by JSSO.