Friday, August 12, 2011

OpenSSO/OpenAM : Session Timeout for Login Page

The following is the page most customers hate. 

Unlike other web-based applications, the OpenSSO/OpenAM login page itself has a timeout value. The clock starts ticking when users land on this page. If users do not login before the timeout, the "Your session has timed out" will be displayed. The default value is 120 seconds.

How can we increase this value? This is the most common question from customer.

[openam953]$ cd /home/openam953/opt3/tomcat/webapps/openam953/config/auth/default_en
[openam953]$ vi DataStore.xml

Change timeout from 120 to 300. I personally think 5 minutes is a reasonable value. Why would one come to a Central Single Sign-On page to do nothing? Most probably, one would want to authenticate and be quickly redirected to the intended application.

I somehow had this impression that a timeout value of 0 implies there will be no session timeout. With this impression, I implemented this solution for one of my customer in one of the local ministries. The feedback was the Login Page times out even faster. Strange! :)

After much debug, I then realized 0 is not an accepted value. If 0 is input, a default value of 60 seconds will be applied.

[openam953]$ tail -f Authentication | grep -i "timeout"

Setting page timeout :60
Returning page timeout :60
Setting page timeout :120 <- Default Login Page value

Setting page timeout :60
Returning page timeout :60
Setting page timeout :600 <- This was when I set the timeout value to 600

Setting page timeout :60
Returning page timeout :60
Setting page timeout :60 <- If 0 is input, it will be replaced by 60

This default value can be found in PagePropertiesCallback.

And also, do take note of Invalidate Session Max Time in Session Limits.

The default value is 3 mins. In my case, I should set it to 6 mins instead.


Tuesday, August 2, 2011

Weird behavior in OpenAM 9.5.3 RC1 when configured with external configuration data store

OpenAM 9.5.3 stable release was released today. The download link is here.

Prior to this stable release, I was using 9.5.3 RC1 for a demo and discovered a weird behavior. Luckily,  it's gone in 9.5.3 stable release.

The issue only happened when an external configuration data store is used. In my case, I was using OpenDJ 2.4.2.

As with any default OpenAM installation, the log level was set to ERROR. I wanted to debug my deployment, thus I went ahead to set the log level from ERROR to MESSAGE via the OpenAM Administration Console.

Set Debug Level to "Message".

Everything ran fine. The verbose logging was output. However, once I restarted the web container, I'll not be able to get to the Login page anymore.

The Session log threw the following error:

amSSOProvider:08/02/2011 04:48:45:718 PM SGT: Thread[main,5,main]
SSO token ldap auth successful for AuthPrincipal: cn=dsameuser,ou=DSAME Users,dc=opensso,dc=java,dc=net
amSession:08/02/2011 04:48:45:777 PM SGT: Thread[main,5,main]
ERROR: SessionService.SessionService(): Initialization Failed
at com.iplanet.dpro.session.service.SessionService.(
at com.iplanet.dpro.session.service.SessionService.getSessionService(
at com.sun.identity.authentication.service.AuthD.getSS(
at com.sun.identity.authentication.service.AuthD.initAuthSessions(
at com.sun.identity.authentication.service.AuthD.(
at com.sun.identity.authentication.service.AuthD.getAuth(
at com.sun.identity.authentication.UI.LoginLogoutMapping.initializeAuth(
at com.sun.identity.authentication.UI.LoginLogoutMapping.init(

The fastest workaround was to change the LDAP value in the external configuration data store from MESSAGE back to ERROR.

Change to "ERROR".

Restarted web container. Solved. Everything back to normal. Very weird.  ( I tried Tomcat 6 and Glassfish 2.1, both threw the same error if external configuration data store is used )

Today, I tried OpenAM 9.5.3 with embedded and external config data store. Both work!

Out of curiousity, I tried OpenAM 9.5.3 RC1 with embedded config data store. It works! So it's only with external config data store, then it fails. Hmmmm....