3

While using CA Siteminder's JAVA SDK API we noticed a starnge issue that sometimes the init fails randomly. Also re-initializtions happens later with no change in the system. It's little alarming and unexpected. Since AgentAPI is majorly connecting to policy server, there's no point where it will have issues with resource (like system ports) but still the issue happens. Did anybody notice such a behaviour with CA Siteminder anytime?

Soumen
  • 996
  • 1
  • 10
  • 19
  • Are you using the pure java agent api or the JNI based agent api? I believe there are two. Also, how are you using this? Is it a custom agent being loaded by siteminder? If so, it's probably using JNI to load your code. I've seen mine loaded multiple times. It seems to unload it after a period of time and reload it. I don't really see an issue with that so long as you can clean up resources. beyond that - how is init failing? are you getting any log messages? are you doing anything in your init() to cause potential failures? – Trever Shick Jul 05 '11 at 23:08
  • i am using java agent api not the JNI one. What i am doing is connect to Siteminder Policy server using the Java agent API. Sometimes the Agent.Init() call fails in getting initiaklized properly and sends a failure result. Quite strange behaviour sisnce many a times it works properly – Soumen Jul 06 '11 at 13:52
  • #1 Just to be clear... It's YOUR init() method that's failing in your agent correct? #2 Are you able to post any of your init() code? #3 Is your java code standalone code or being loaded by the webagent by chance? If it's being loaded by the web agent then it's being loaded via JNI and the init methods appear to be called only when loaded by JNI not when you might expect. I had a similar issue with a custom auth scheme i wrote where init() wasn't called somtimes, and sometimes it was. – Trever Shick Jul 09 '11 at 11:08

1 Answers1

1

Finally it was figured out by CA Siteminder team. The reason cited out was the random number generator inside the ssl handshake. The RNG took more time to gain certain entropy by which server was timing out. It's an intresting case and the solution suggested was using /dev/urandom instead of /dev/random to get a fast RNG.

Soumen
  • 996
  • 1
  • 10
  • 19