WLS Session Cookie Overriding in an OAM/SSO Enabled Environment

First I’d like to remind everybody about the Identity Management 11g launch that is coming up. You can register for it here.

With that out of the way, today I’d like to conclude my series of posts on user session management in OAM/SSO enabled environments by talking in detail about the issue of WLS session cookie overriding.

The Problem

To review, if OAM is protecting multiple containers or applications that by default issue session cookies with the same name then it is important to realize that as a user moves from one container/application to another that the session cookie of the 2nd container/application will blow away the session cookie from the first container/application.

An example of this is OAM protecting multiple WebLogic applications that are not sharing a session. The JSESSIONID cookie issued when a user accesses a second application will blow away the JSESSIONID from the first application.

Now, what you usually see in such a setup is that the user can go back and access the first application without having to login again. However, underneath the covers they will be issued a new session. So, upon returning to the first application, any data associated with their original session will be lost and the application flow may be disrupted or different from the expected behavior.

Solutions

As far as I know there are 3 possible solutions to this issue:

1. Enable session sharing between your WLS applications.
2. Configure distinct WLS session cookie names (instead of JSESSIONID) for each application so that they won’t override each other.
3. Configure distinct cookie paths for each application (by default the JSESSIONID created by WLS has a path of “/”) so that they won’t override each other.

None of these solutions is perfect, so we’ll now go through and discuss the advantages, disadvantages, and limitations of all 3.

Session Sharing

By default, applications do not share the same WLS session. However, for applications deployed in the same EAR, it is pretty easy to set it up so that they do share the user session. The main limitation here is that the applications have to be deployed in the same EAR.

To enable session sharing between applications in an EAR, set the sharing-enabled attribute in the session descriptor to true in the weblogic-application.xml.

Changing the Session Cookie Name

Going the route of giving unique names to the session cookie for each application is a solid solution and realistic solution to the session cookie overriding problem. However, there are a few draw backs that I’ll get to.

First, let’s talk about how to change the WLS session cookie names. On the application side, you set the cookie-name deployment descriptor variable in the weblogic.xml. If you are fronting WebLogic with a real web server, you’ll need to configure the mod_wl connector “routing rules” with the appropriate cookie name to be used for each application. Specifically with regard to OHS/Apache and mod_wl_ohs, the appropriate directive is WLCookieName. The following is an example mod_wl_ohs configuration using this directive:

Sample mod_wl (httpd.conf/mod_wl.conf) configuration

#### /AppA

SetHandler weblogic-handler
WebLogicHost test_server1
WebLogicPort 7001
WLCookieName cookie1
DynamicServerList OFF
Debug ALL
WLLogFile logs/httpd_proxy1.log


#### /AppB

SetHandler weblogic-handler
WebLogicHost test_server2
WebLogicPort 7001
WLCookieName cookie2
DynamicServerList OFF
Debug ALL
WLLogFile logs/httpd_proxy1.log

#### /AppC

SetHandler weblogic-handler
WebLogicCluster machine_1:7001,machine_2:7001
WLCookieName cookie3
Debug ALL
WLLogFile logs/httpd_proxy1.log


As you can see this does complicate your mod_wl configuration some in that you have to isolate the context-root of every application that is to have a unique cookie. You’ll also have to then distribute updates to every http server in your deployment. One other issue you might encounter with this solution is that you might have infrastructure software like monitoring software that is hard coded or pre-configured to look specifically for JSESSIONID. If you change the name of the session cookie your monitoring may break. Finally, some black box commercial applications that run on WebLogic cannot be changed to use alternative cookie names.

Changing Session Cookie Paths

Setting the “cookie path” of the session cookie for each application to the context root of the application allows you to maintain separate WLS session cookies for each application without having the cookies for different applications overwriting each other.
To implement this you simply need to set the cookie-path deployment descriptor variable in the weblogic.xml. One advantage to this approach is there are no required configuration changes on the web server / mod_wl side of things.

On the downside, the problem of black box applications running on WLS is arguably worse with the unique path solution than with the unique name solution. Just like with the cookie name, some black box commercial application that run on WebLogic cannot be changed to use different cookie paths and most of these have hard coded cookie paths set to “/”. In such situations these black box applications will not only interfere with each other, but you also will get conflicts between the black box applications and your custom applications for which you are properly setting the paths to the context root. From my little bit of testing of browser behavior it seems that the more specific path always wins so it seems it is mainly an issue of the session cookies for the black box apps being overwritten by your applications session cookies. In any case, it is definitely something to be aware of.

Conclusion

WLS Session Cookie Overriding is a common problem in an OAM/SSO enabled environment. There are 3 possible solutions to the problem: session sharing, application unique session cookie names, and application unique cookie paths.

However, all 3 solutions have their limitations.