- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
RSA INTEGRATION ISSUE WITH WILDFLY 8.2.1 working fine with jboss .
Hi,
We are using RSA with our product for single sign on.
We use rsacookieapi.jar and librsacookieapi.so 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 librsacookieapi.so file.
and
/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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Regards,
Erica
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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').
