SecurID® Discussions

Browse the SecurID discussion board to get product help and collaborate with other SecurID users.

RSA INTEGRATION ISSUE WITH WILDFLY 8.2.1 working fine with jboss .



We are using RSA with our product for single sign on.

We use rsacookieapi.jar and  files and we add it to the wildfly SERVER lib folder as mentioned in documnet :- RSA Authentication Agent 5.3 for Web Authentication Developer’s Guide for Apache Web Server on Red Hat Linux 4.0 .

This was working fine with JBOSS 4.2.3 server(followed same Doc.) but not working with the wildfly 8.2.1 server.


Below is the structue of placing files in wildfly server:


/opt/wildfly-8.2.1.Final/standalone/deployments/xyz.ear/lib  for file.


/opt/wildfly-8.2.1.Final/standalone/deployments/xyz.ear/abc.war/WEB-INF/lib for rsacookieapi.jar


After debugging we could see the error as Could not initialize class com.rsa.cookieapi.RSACookieAPI.

Please let us know if we are missing anything?

2 Replies
Employee (Retired) Employee (Retired)
Employee (Retired)

Abhilash k‌,


I've moved your question to the RSA SecurID Access" data-type="space where it will be seen by the product's support engineers, other customers and partners.  Please bookmark this page and use it when you have product-specific questions.


Alternatively, from the RSA Customer Support page, click on Ask A Question on the blue navigation bar and choose Ask A Product Related Question.  From there, scroll to RSA SecurID Access" data-type="space and click Ask A Question.  That way your question will appear in the correct space.




Trusted Contributor Trusted Contributor
Trusted Contributor

I would double check that some of the other required configuration settings are in place for the server. I would specifically check the LD_LIBRARY_PATH. More detailed information may be required for further diagnosis. The message "Could not initialize class:..." was no doubt followed by additional details such as "class not found" or "exception thrown in constructor". These are critical to understanding the problem.


I would also question the locations you've listed above.  I believe these directories may be recreated/overwritten if their respective EARs or WARs are re-deployed. I would recommend placing these files in a different directory and referencing them in this different location via the CLASSPATH (for the jar) or LD_LIBRARY_PATH (for the JVM to be able to load the '.so').