SM Agent API is using previous App ID instead of current App ID when requests are in rapid succession

Products

• SITEMINDER

Issue/Introduction

We are generating a smsession by connecting to the SiteMinder Policy Server using SM Agent API.
We found that while generating an SMSESSION cookie SDK is taking the previous App ID to instead of current App ID to generate the session. What that means is:

Let's say we just made a call using the SDK for userID_1 to generate an SMSESSION, now in a quick 3-4ms time window we made another call using the SDK for userID_2, but in the SMSESSION cookie we can see the user is still userID_1 whereas it should have been userID_2 in the SMSESSION.

Environment

Release : ALL

Component : SITEMINDER -SDK

Cause

The problem looks to be copying of a stack-based parameter (to one of their functions) into a member variable (to only avoid passing it to another simple function) but the instance of the object might be called from multiple threads.

There is no direct evidence that the same instance of the object is being called from multiple threads, but this code looked highly suspicious.

Resolution

We had them remove the member variable, reference the parameter passed as an argument instead, and change their simple helper function to accept the parameter (no longer needing to use a member variable).

We suggested that they add logging of the instance ID to their log, e.g. Object.toString() which logs the object type and instance ID by default. This might show multiple threads accessing the same instance ID as direct evidence that they are on the right track.

Finally, they were initializing then uninitializing the agent API on each call - maybe in an attempt to correct their multi-thread unsafe code. We suggested they instantiate the AgentAPI object during their application initialization and to call the AgentAPI.uninit() when the application is being shut down (by the Java servlet container).