Problem

Integrating with OAM 10g requires both a 10g and an 11g ASDK and it's not clear what each component is used for or how the connections are managed.

Resolution

The API Gateway uses the 11g ASDK in 10g compatibility mode in order to connect to an OAM 10g server. The 10g ASDK is only used to generate the 10g configuration files used by the agent (e.g. ObAccessClient.xml). We use the 11g ASDK in 10g compatibility mode to make the actual connections to the OAM 10g server. All of the actual connections are made by the oracle.security.am.asdk.UserSession object.

For 11g, we need to guard against hitting the server-side OAM "max sessions per user" limit, which Oracle recommends to be set to 20. This means that if the gateway is generating a new UserSession for each user request, the user can only send 20 requests within their idle/max timeout period before they hit the "max sessions per user" limit.

To mitigate against this, we keep a cache of UserSessions keyed on username and password. When the user sends a request, we first check the cache for a current, valid session for this user. If there is one in the cache, we can return this UserSession. If not, we generate a new UserSession. The key to making this work is to call getStatus() on the UserSession object returned from the cache before returning it. If the user's idle/max timeout has expired, the session will be logged out (and removed from the cache) and a new UserSession will be created.

Note that this works because the user is sending up their credentials (i.e. authenticating) with each request. So if the session has expired, we need to create another one rather than, say, failing the filter and forcing them to login again. To configure this behavior, the client should send up the token in a HTTP header, for example, and a Validate SSO Token filter can validate the token. If the token is valid, continue; otherwise, AuthN the user from scratch.

For 10g, we can create a new UserSession for each request since sessions are not stored on the server. All the information relevant to the session is stored in the session itself. Therefore, the gateway will never cache UserSessions when operating in 10g compatibility mode.