- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
How does AuthSDK find rsa_api.properties in tomcat context?
I am using the AuthSDK_Java_v8.6... in a web application packaged as a war file.
I have installed, configured and tested the PAM-Agent_v7.1.0.1.25 on the redhat server running tomcat6, and successfully authenticated using the "acetest" application that installs with that agent.
I am running into a problem in that the AuthSessionFactory.getInstance(); which I have as part of the HttpServlet.init() implementation is as expected not finding the sdconf.rec file in its standard location (/var/ace). The proper fix for this is of course to use an rsa_api.properties file and configure the locations.
My problem is that I don't know where I should put the rsa_api.properties file. Should it go:
1) Somewhere within the war archive structure?
2) somewhere in the /usr/share/tomcat6 directory structure?
3) in /etc?
4) elsewhere?
If it gets located outside of the war file, what selinux tag should I tag the rsa_api.properties file?
- Tags:
- apache_tomcat
- CAS
- Cloud
- Cloud Auth
- Cloud Authentication
- Cloud Authentication Service
- Community Thread
- Discussion
- Forum Thread
- java client
- properties
- RSA SecurID
- RSA SecurID Access
- SaaS
- SecurID
- tomcat
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
For Java, rsa_api.properties belongs in your application current 'working' directory.
Java applications have no concept of changing the "current working directory" so this location (i.e. "." is always the directory where the java application was started.
In terms of Tomcat, the "current working directory" is dependent both on the version of Tomcat you are using and the particular mechanism you used to start the service.
(a) The root directory of your Tomcat installation (e.g. "...\Apache Software Foundation\Tomcat 8.5")
(b) the bin directory within this folder.
To be absolutely sure you should include code in your application to locate the current directory, for example:
File currentDir = new File(".");
if (DEBUG) {
LOG.debug(" Loading config files from from directory [" +
currentDir.getCanonicalPath() + "]");
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Ed's answer is correct.. but you probably have a larger problem.. what Java version are you using? Tomcat 6 is VERY old.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Edward,
Thank you for the answer. The problem is that I have no idea whatsoever what the "current working directory" is within a tomcat servlet context. If I were running a Java application say from an executable jar file, that would be easy to ascertain. running under a servlet container clouds the issue entirely.
-Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
Sean,
I agree. Tomcat6 is very old... However, until IA approves the next vendor update for field use, I am stuck with it.
The java version is build 1.7.0_55-b13.
-Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
I made more edits to my first answer, I believe the tomcat /bin dir is what you need to use.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
in RSA PS we have built a REST web services wrapper around the auth SDK that has a home directory defined in the application framework.. have you tried the webapps directory for your application? I will ask the head dev how he establishes the base directory for the sdk when it's invoked by the servlet engine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
JRE 1.7 won't support TLS 1.2 lockdown mode.. so that's yet another problem..but as long as it's not.. should work.
