This topic has 6 replies, 3 voices, and was last updated 1 week, 1 day ago by 
-
Posts
-
Hi all,
I want to increase the validity of the HOTP link that is delivered via email.1. I have changed the value for property “One Time Password Validity Length” from 5 minutes to 15 minutes. After testing it, I noticed that it is not working.
2. I have also modified the value of the “com.iplanet.am.session.invalidsessionmaxtime” property under the Deployment -> Session -> Session Limits -> Invalidate Session Max Time from 3 minutes to 16. After testing it, I noticed that it is not working as well.
I noticed that the HOTP Token expires before the specified time in Validity length and that is valid for 3 minutes and not 5 minutes or more. Is there any other value that needs to be changed?Any help would be much appreciated. Thank you!
VassilisHi Vassilis
Which version of AM?
The com.iplanet.am.session.invalidsessionmaxtime property on its own will not have the desired effect. There are some XML files that need to be edited as well. See the article https://backstage.forgerock.com/knowledge/kb/article/a23597700. Pay particular attention to changing the correct XML files if you have multiple realms and/or locales.
-Andy
Hi Andy,
Thank you for the reply and the information provided. The current version of AM is 5.5.
I took a look in the XML files and I guess the ones that needs to be changed are HOTP.XML and LDAP.XML. Can these be changed on the bash and how I will be sure that the changes will be applied after deployment?Vassilis
Hi Vassilis
Are you using Tomcat as the container? (Or another container that explodes the AM WAR file into the files that it uses at runtime.) If so, yes – you can use an editor from bash to change the files in place. From memory, I believe you would need to restart the container for the new values to take effect. Changing the files in place is OK, but if the container decided to explode the WAR file again your changes would be lost. To avoid this, you could either change the XML files inside the WAR file itself, or ensure that new XML files are copied across as part of an automated build process.
-Andy
Hi Andy,
We are using Tomcat inside the container, not as the container. But if I restart the container, are the new files in place or will they disappear?
To avoid this, you could either change the XML files inside the WAR file itself, or ensure that new XML files are copied across as part of an automated build process.
Could you please provide with more information on how to do this, and where the WAR file is located?
Thank you,
VassilisPackaging a WAR is more of general tomcat thing see discussions such as:
https://stackoverflow.com/questions/19269961/how-to-unpackage-and-repackage-a-war-file/19270036
The War is the openam.war that is normally located in your webapps directory for tomcat.
Hi Vassilis
I meant Tomcat as a web app container, or application server, rather than a devops-style container, which perhaps you meant. Never mind – restarting the container (of either type!) should not remove the files you copy into the runtime location. If you have an automated build then copying files into the exploded WAR location is a good solution as you can guarantee they won’t be forgotten on a new build. Otherwise, repackaging the WAR is safer in my view. William’s answer is a good one, using the ‘jar’ command line tool is quick and easy. You could also look at a Maven WAR overlay, https://maven.apache.org/plugins/maven-war-plugin/overlays.html, though that’s probably overkill unless you were to be making other WAR customisations.
-Andy
You must be logged in to reply to this topic.
