A bit about Multiple Web Applications, Cookies, and Authentication

By default, WebLogic Server assigns the same cookie name (JSESSIONID) to all Web applications. When you use any type of authentication, all Web applications that use the same cookie name use a single sign-on for authentication. Once a user is authenticated, that authentication is valid for requests to any Web Application that uses the same cookie name. The user is not prompted again for authentication.

If you want to require separate authentication for a Web application, you can specify a unique cookie name or cookie path for the Web application. Specify the cookie name using the CookieName parameter and the cookie path with the CookiePath parameter, defined in the WebLogic-specific deployment descriptor weblogic.xml <session-descriptor> element. For more information, see “session-descriptor” in Managing Server Startup and Shutdown for Oracle WebLogic Server.

If you want to retain the cookie name and still require independent authentication for each Web application, you can set the cookie path parameter (CookiePath) differently for each Web application.

WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. This feature enables Web site designers to prevent session stealing. For more information on this feature, see Using Secure Cookies to Prevent Session Stealing.

Using Secure Cookies to Prevent Session Stealing

A common Web security problem is session stealing. This happens when an attacker manages to get a copy of your session cookie, generally while the cookie is being transmitted over the network. This can only happen when the data is being sent in clear-text; that is, the cookie is not encrypted.

WebLogic Server allows a user to securely access HTTPS resources in a session that was initiated using HTTP, without loss of session data. To enable this feature, add AuthCookieEnabled=”true” to the WebServer element in config.xml:

<WebServer Name="myserver" AuthCookieEnabled="true"/>

Setting AuthCookieEnabled to true, which is the default setting, causes the WebLogic Server instance to send a new secure cookie, _WL_AUTHCOOKIE_JSESSIONID, to the browser when authenticating via an HTTPS connection. Once the secure cookie is set, the session is allowed to access other security-constrained HTTPS resources only if the cookie is sent from the browser.

Thus, WebLogic Server uses two cookies: the JSESSIONID cookie and the _WL_AUTHCOOKIE_JSESSIONID cookie. By default, the JSESSIONID cookie is never secure, but the  _WL_AUTHCOOKIE_JSESSIONID cookie is always secure. A secure cookie is only sent when an encrypted communication channel is in use. Assuming a standard HTTPS login (HTTPS is an encrypted HTTP connection), your browser gets both cookies.

For subsequent HTTP access, you are considered authenticated if you have a valid JSESSIONID cookie, but for HTTPS access, you must have both cookies to be considered authenticated. If you only have the JSESSIONID cookie, you must re-authenticate.

With this feature enabled, once you have logged in over HTTPS, the secure cookie is only sent encrypted over the network and therefore can never be stolen in transit. The JSESSIONID cookie is still subject to in-transit hijacking. Therefore, a Web site designer can ensure that session stealing is not a problem by making all sensitive data require HTTPS. While the HTTP session cookie is still vulnerable to being stolen and used, all sensitive operations require the _WL_AUTHCOOKIE_JSESSIONID, which cannot be stolen, so those operations are protected.

You can also specify a cookie name for JSESSIONID or _WL_AUTHCOOKIE_JSESSIONID using the CookieName parameter defined in the weblogic.xml deployment descriptor’s  <session-descriptor> element, as follows:

<session-descriptor>
    <cookie-name>FOOAPPID</cookie-name>
</session-descriptor>

In this case, Weblogic Server will not use JSESSIONID and _WL_AUTHCOOKIE_JSESSIONID, but FOOAPPID and _WL_AUTHCOOKIE_FOOAPPID to serve the same purpose, as shown in Table below.

wlcookies

Further reading..