February 23, 2018 at 9:15 am #21000
I am trying to install OpenAM 5.5.1 war file for the first time on tomcat7 instance. While trying to setup the first custom site, configuration wizard fails with below exception. I tried to look around this issue and it seems like most of them are pointing to configuration change of “ssoadm” as mentioned in below link. But I couldnt find where it exists. May be I couldnt find becoz my installation is not finished.
Can someone help me here to over come this issue?
02/23/2018 08:06:48:488 AM UTC: Reinitializing system properties.
AMSetupServlet.processRequest: errorcom.sun.identity.security.AMSecurityPropertiesException: AdminTokenAction: FATAL ERROR: Cannot obtain Application SSO token.
at com.sun.identity.setup.AMSetupServlet.processRequest(AMSetupServlet.java:473)February 23, 2018 at 11:15 am #21004
Are you configuring AM from the web admin console? If so, I’m not sure why you would get that error, but I think references to ssoadm are a red herring. The ssoadm executable is a command line tool that can be used to configure AM in scripts. If you don’t know about it, I’m guessing you aren’t using it. The KB article you mention describes the same symptoms, but is purely about altering the ssoadm script to cater for a site configuration, so won’t be your issue.
-AndyFebruary 23, 2018 at 6:58 pm #21008
Thanks Andy for the response.
I am configuring OpenAM for the first time through Web. I am not using any scripts to install OpenAM. Below are the steps I did.
1) Installed tomcat on linux vm
2) Deployed AM-eval-5.5.1.war as ROOT.war into webapps folder and restarted tomcat
3) Go to http://<tomcathost>:8080/
4) Went through “Custom Site Configuration” link
5) Went through all the screens by providing details for Local configuration OpenAM Store, User Store and Loadbalancer Site information.
6) Wizard started configuration and errored out with above exception.
Do I still have to modify any properties in the WAR file to get around this issue?
Thanks.March 4, 2018 at 3:57 pm #21086
Does the same thing happen if you deploy AM under a non-root context, say sso.war?March 6, 2018 at 10:14 pm #21118Scott HegerParticipant
As per the Note shown here: https://backstage.forgerock.com/docs/am/5.5/install-guide/#deploy-openam
To properly configure AM, AM requires a deployment URI with a non-empty string after /. Do not deploy AM at the root context. Do not rename the .war file to ROOT.war before deploying on Tomcat, for example.March 6, 2018 at 10:16 pm #21119Scott HegerParticipant
Oh, and for best practice don’t deploy it as openam.war. Use something like Andy suggested like sso.war or other common choices are auth.war, login.war….mickeymouse.war…..j/k. Basically anything other than ROOT.war and openam.war.March 7, 2018 at 9:17 pm #21126
Thanks for pointing that out Scott. Will try it and let you know how it goes with 5.5 version.
As I am trying to evaluate the product for a quick POC, I tried installing OpenAM 13.0 version and It is up and running. I installed it as openam.war according to documentation. It seems like version 13.0 doesn’t seem to have issues with the name as “openam.war”
Will have to integrate OpenAM with OpenIG 4.0 for a quick OpenIDConnect POC.
NavMarch 8, 2018 at 11:43 am #21139
Unlike using ROOT.war, there’s no technical reason you can’t use openam.war. Scott’s advice was more around best practice. Using something generic like sso.war or auth.war doesn’t advertise the vendor of your SSO platform.
-AndyMarch 8, 2018 at 6:45 pm #21150
Got it. Thanks, Andy and scott for your inputs on this issue and suggestion on best practice. Let me try by changing it to different name and redeploy the WAR.
You must be logged in to reply to this topic.