The Ultimate Apache/OHS11g Tuning Guide for OAM11g WebGate

Introduction OK, maybe “Ultimate” could be stretching it, but it caught your eye so you can be the judge. This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available here. Though OAM11g is […]

OAM 11g Webgate Tuning

INTRODUCTION This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. People typically are introduced to Webgate tuning in one of two ways, either forced into it because of a crisis or […]

OAM11g — The Redirect Infinite Loop

INTRODUCTION This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available. I recently was working on one of my virtual environments that had three servers, which included OAM 11gR2PS2, though this […]

How To Display A Custom Error Page When the Access Server Is Down?

I have been asked several times over the years if there is a way to customize the following error message a User is presented in their Internet browser when the WebGate fails to contact any of the Access Servers. Oracle Access Manager Operation Error The WebGate plug-in is unable to contact any Access Servers. Contact […]

Strategies for managing OAAM to OAM connections in production

Many Oracle Access Management 11g customers opt to deploy a combination of Oracle Access Manager and Oracle Adaptive Access Manager using the Advanced Integration option. This combination of product features can provide strong, adaptive authentication and fraud mitigation for online applications. In this post, we examine a number of strategies for configuring the connectivity between […]

OAM WebGate connections through firewalls

Introduction In this post, we investigate a complication that can occur if you require a firewall between your WebGate agents and your OAM 11g servers within your deployment topology. We provide some guidance related to how to configure your WebGates in this case. This post is part of a larger series on Oracle Access Manager 11g […]

Webgate Reverse Proxy Farm

Introduction Some of our larger deployments are seeing the benefits of centralizing their Webgate deployments onto a server farm. This post discusses some of the architecture and recommendation when deploying such an architecture. All content listed on this page is the property of Oracle Corp. Redistribution not allowed without written permission

How many connections do I need from the WebGate to the OAM Server?

Someone just asked the question: My question is that, if we have 2 oam servers and assign 1 as Max Number of Connections for each server, does this mean that the webgate can handle only 2 connections at a time? Do we need to increase this value to enab…

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.

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:

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.