Oracle Access Manager (OAM), SSO and Session Management

The subject for today is understanding user session management in an OAM/SSO enabled web application environment.

Some people think that once OAM is deployed, that the OAM session which is represented by the OBSSO Cookie replaces application or container (app server, .net, PHP etc) specific sessions. This is not the case. Application and container specific sessions still exist. It is just that rather than logging into a specific application to initiate the application or container session, the session will be initiated automatically if the user has an existing OBSSO cookie. Thus, as the user moves from one container or application to another, they initiate new user sessions without having to re-authenticate.

For all its glory, the introduction of OAM creates a few nuanced issues for architects of web applications to navigate:

Session Timeouts
It is important to be aware of the relationship between the session timeout values in OAM and session timeouts for container/application sessions.

OAM sessions have both idle and maximum session timeout controls. Most container/application sessions control only the maximum length of the session.

Ideally, your OAM and container/application sessions will timeout at the same time but it is important to understand what happens if they don’t. Even if your session timeouts are set to the same value, the OAM session can timeout before an application session if a user moves from one container to another in the same OAM session. This is because the 2nd container/application session will have started well after the OAM session.

So, if a user’s OAM session expires before their container/application session, they will be blocked at the web server (or proxy server) by the OAM webgate and asked to re-authenticate. Upon re-authenticating, they will be let through to the application. What happens next depends on the details of the integration between OAM and the container or application.

If a new login to OAM always results in a fresh application/container session then everything will work as you expect.

If however, the existing application session from before the OAM session timeout is still in place then the user of the browser will continue with that session. This is fine as long as the user re-authenticating is the same as the original user. In the case of extranet applications, applications used from shared systems or even just applications that are accessible from the public it is important to put measures in place to ensure that the user associated with the OAM session is the same as the user associated with the application session. See session synchronization below for more on this.

Logouts
If your pre-OAM enabled application has logout capabilities, you will want to synchronize this capability with an OAM logout. OAM logs a user out when they access a logout URI. Logout URIs are configurable in OAM and can be set to pretty much anything. By default, OAM will log a user out when they access any URI ending in logout.* where * is anything other than gif or jpg.

Session Synchronization
For applications that can be accessed from external/uncontrolled networks, especially public extranet applications, it is a good idea to put measures in place to make sure that the user associated with an active OAM session is the same as the user associated with an active container/application session being protected by OAM.

What you are trying to avoid is a situation where users either intentionally or accidentally log in to OAM as themselves but access the application as someone else.
The basic idea is to have a filter in place that compares the user in the OAM session to the user in the application/container session. Fusion Middleware 11g contains such a filter called the SSO Synchronization Filter. You can read more about it here: http://download.oracle.com/docs/cd/E15523_01/core.1111/e10043/osso.htm#CHDHDBED

Session Cookie Overriding
Finally, 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.