Siebel Security Guide > Security Features of Siebel Web Server Extension > About Using Cookies with Siebel Business Applications >

Session Cookie

The session cookie consists of the session ID generated for a user's session. This cookie is used to manage the state of the user's session. The session cookie applies to the Siebel Web Client only.

Cookie modes are determined on the SWSE by the setting of the SessionTracking parameter in the eapps.cfg file. For information about setting parameters in the eapps.cfg file, see Configuration Parameters Related to Authentication.

The SessionTracking parameter settings are:

• Automatic

  Using the default SessionTracking setting of Automatic, the SWSE runs in cookie-based mode. Session information is maintained through cookies. However, if a browser does not support cookies or if a user's browser is configured to not allow cookies, then the SWSE will function in cookieless mode and use URLs instead. A cookieless session is invoked when the browser does not send back a session cookie to the Siebel Web Engine.

• Cookie

  To force the SWSE to always use cookie-based mode, set the following parameters in the eapps.cfg file to the values shown:

  SessionTracking = Cookie
  URLSession = FALSE
  CookieSession = TRUE

  If you set SessionTracking to Cookie, Web browsers with cookie handling disabled cannot maintain a Siebel user session.

  NOTE:  If you have implemented Web Single Sign-On as your method of user authentication, then, for security reasons, it is recommended that you implement cookie mode by setting the SessionTracking parameter to Cookie.

• URL

  Siebel Open UI clients do not support cookieless mode. However, if you are using a Siebel high-interactivity client or a Siebel standard-interactivity client, you can force the SWSE to always use cookieless mode by setting the SessionTracking parameter to URL. Session information is passed through the URL.

  You might have to implement cookieless mode if security requirements in an organization do not permit the use of cookies. However, this option is not secure and is not recommended for customer-facing deployments of Siebel Business Applications.

Some Siebel application requirements relating to the settings of the SessionTracking parameter are as follows:

• The Quick Print feature requires that you set SessionTracking to either Automatic (the default) or URL. For information about using this printing feature, see Siebel Fundamentals. For information about browser requirements for this feature, see Siebel System Administration Guide.
• Inbound EAI HTTP Transport requires cookie-based mode. You can omit the SessionTracking parameter, or set it to either Automatic (the default) or Cookie, in each eapps.cfg file section whose name starts with eai. For more information about inbound EAI HTTP Transport, see Transports and Interfaces: Siebel Enterprise Application Integration and other relevant Siebel EAI documentation.
• The Remember My User ID functionality requires that you set SessionTracking to either Automatic (the default) or Cookie. Make sure that cookies are enabled in the browser. See also the description of the auto-login credential cookie in Auto-Login Credential Cookie.

Cookie-Based Mode and Cookieless Mode

This topic describes how session IDs are generated and processed in cookie-based and cookieless mode. The mode employed is determined as follows:

• Cookie-based mode applies when SessionTracking is set to Cookie, or when SessionTracking is set to Automatic and the user's browser accepts cookies.
• Cookieless mode applies when SessionTracking is set to URL or when SessionTracking is set to Automatic and the user's browser does not accept cookies.

When a Siebel Web Client user successfully logs into Siebel Business Applications, a unique session ID is generated for that user. The steps involved in a user session are as follows:

1. The components of the session ID are generated in the Siebel Server and sent to the Session Manager running in the SWSE.
2. The session ID is passed to the client either in the URL or in a cookie as determined by the value of the SessionTracking parameter. Depending on the mode implemented, the following occurs:
   • In cookie-based mode:
     • The session ID is passed to the user's browser in the form of a nonpersistent cookie which is stored in memory. It stays in the browser for the duration of the session, and is deleted when the user logs out or is timed out.
     • For every application request that the user makes during the session, the cookie is passed to the Web server in an HTTP header as part of the request.
     • The SWSE parses the incoming cookie to obtain the session ID and, if the ID is valid, processes the request. If the HTTP header does not include a cookie containing a valid session ID, then the Web server does not honor that request.
   • In cookieless mode:
     • The session ID is passed to the user's browser as an argument in the SWSE construct of the URL. The browser stores the session ID in memory until the session ends.
     • For every application request that the user makes during the session, the request URL includes the session ID.
     • The SWSE parses the incoming request URL to obtain the session ID and, if it is valid, processes the request. If the session ID is missing or not valid, then the Web server rejects the client request.

Using Secure Cookies

To increase the security of session cookies, Siebel Business Applications assign the Secure attribute to all session cookies by default. Setting the Secure attribute for cookies specifies that the cookies are to be transmitted to Web servers only over HTTPS connections, that is, to Web servers that have enabled SSL.

The EnableSecureCookie parameter is used to configure whether or not the Secure attribute is set for Siebel session cookies. If the parameter is set to True, then the Secure attribute is set for all session cookies. If the parameter is set to False, then the Secure attribute is not assigned to session cookies.

The following procedure describes how to configure secure cookies.

To enable secure cookies

1. Navigate to the eapps.cfg file in the SWEAPP_ROOT\bin directory.
2. In the [swe] section of the eapps.cfg file, set the value of the EnableSecureCookie parameter to True, which is the default value.
3. Verify that the Siebel Web server is configured to support HTTPS.

   If you set the EnableSecureCookie parameter to True, but the Siebel Web server does not support HTTPS communications, then the Secure attribute is not assigned to Siebel session cookies and the cookies can be sent over HTTP connections between the Siebel Web server and the Siebel client.

Session ID Encryption

The session ID is composed of the applicable server ID, process ID, and task ID, combined with a timestamp. All values are in hexadecimal form, as shown:

server_ID.process_ID.task_ID.timestamp

For example, the session ID might resemble the following:

sn=!1.132.6024.3ca46b0a

You can optionally choose to encrypt the session ID in the URL (cookieless mode) or in the cookie (cookie-based mode). To encrypt the session ID, set the EncryptSessionId parameter to TRUE in the eapps.cfg file.

The RC2 algorithm encrypts the session ID by using a 56-bit encryption key, however, if you are using cookieless mode, the SWSE can specify a different encryption key length. The result of this encryption is then encoded using Base64 Content-Transfer-Encoding. Encrypting the session ID prevents unauthorized users from capturing it and using it in a malicious attack.

You can increase the encryption key length to 128-bits for RC2 and up to 256-bits for AES. To increase the encryption key length, you must use the Siebel Strong Encryption Pack. For more information about the Siebel Strong Encryption Pack, see About the Siebel Strong Encryption Pack.

NOTE:  If the user changes the password during an application session, then the password information in the session ID might no longer allow the user to access Siebel Reports during this session. This is the case when using both database authentication and password hashing. After changing the password, the user must log out and log in again in order to be able to run reports.