Sun Java System Access Manager FAQ: Single Sign-On (SSO) and Sessions

I've reclassified certain user accounts as being inactive, why do their sessions still remain valid?
Can the session timeout values vary for different roles and organizations?
Can I determine whether or not a user is logged in by the pattern of the SSO Token?
How do I prevent hijacking of sessions?
How do I set up notification service?
How do I find out the number of active sessions?
How do I set different MaxSessionTime, MaxIdleTime, or MaxCacheTime values for different users?
How do I enable SSO across multiple domains?
How are Access Manager user sessions stored and maintained?
How do I verify that a session is properly terminated after a logout?
What are the MaxSessionTime and MaxIdleTime session parameters and their possible values?
What is the difference between the max active sessions and max sessions in table settings in the /var/opt/SUNWam/debug/amSSO file?
What is the difference between the session notification mode and polling mode? How does that affect the refreshing of the session client cache?
What value should I set for com.iplanet.am.cookie.encode in the AMConfig.properties file? What are the implications of setting that value to true or false on both the client side and server side?
Where is the documentation regarding the session framework?
How do I resolve the UnsupportedOperationException error after creating an SSO Token with the SSOTokenManager(Principal principal, String password) method?
How do I resolve the Maximum Session Limit Reached error while attempting to log in to the Access Manager Administration Console?
After a user session times out, instead of a redirect to the login page, the session-timeout page is displayed. How do I resolve that error?

Q: After I've reclassified certain user accounts as being inactive, why do their sessions still remain valid?

Reclassifying the user account status does not affect the current sessions. You must manually terminate the sessions you want to inactivate. Afterward or after the users have logged off, users of those accounts will not be able to re-log in.

Q: Can the session timeout values vary for different roles and organizations?

Yes. To configure a value, register the session service for the organization.

In legacy mode:
To set the session timeout at the organization level, create a template for that organization. Click the Properties button for the session service and proceed.

To set the session timeout at the role level, go to the role, click Properties for the session service and proceed.

In realm mode:
To set the session timeout at the realm level, add the session service to the realm. Click the Properties button for the session service and proceed.

To set the session timeout at the role level, add the session service to the role. Click Properties for the session service and proceed.

Note: Support for service registration for the role is available only for the Access Manager SDK plug-in.

Q: Can I determine whether or not a user is logged in by the pattern of the SSO Token?

No. The SSO Token cookie is just a session handle. To validate and obtain the properties that relate to a session, use the session APIs.

Q: How do I prevent hijacking of sessions?

Cookies are notoriously susceptible to snooping, which makes session hijacking difficult to prevent.

Access Manager can check the IP address of a request that contains an SSO Token against the IP address from which the user logged in and the session was created. However, that's no foolproof solution because hackers can spoof IP addresses. Checking addresses also causes difficulties in deployments that involve proxies.

Applying the Secure Sockets Layer (SSL) and enabling the special three-part domain cookie are the best ways to prevent session hijacking. The domain cookie, which is retrieved by Access Manager only and the cross-domain single sign-on (CDSSO) mechanism prevent the cookie from being sent everywhere.

For details, see "Precautions Against Session-Cookie Hijacking in an Access Manager Deployment" in an Access Manager Technical Note.

Q: How do I set up notification service?

See Chapter 9, Enabling the Access Manager Notification Service in the Access Manager Developer's Guide.

Q: How do I find out the number of active sessions?

Do either of the following:

Type amadmin --session. The output lists the active sessions with other related details.
Edit the AMConfig.properties file to turn on stats by changing the related properties as follows:
```
com.iplanet.am.stats.interval=30
com.iplanet.services.stats.state=file
com.iplanet.services.stats.directory=/var/opt/SUNWam/debug
```
With the above configurations, Access Manager records the latest number of active sessions in the debug file amSSO every 30 seconds. For Sun Java Enterprise System installations, that file is /var/opt/SUNWam/debug.

Q: How do I set different MaxSessionTime, MaxIdleTime, or MaxCacheTime values for different users?

Create several roles with session service and assign groups of users. For each of the roles, you can set up a 30-minute session group, a 45-minute session group, and so forth.

Q: How do I enable SSO across multiple domains?

See "Cross-Domain Single Sign-On Session" in the Access Manager Technical Overview.

Q: How are Access Manager user sessions stored and maintained?

Access Manager stores user sessions in a hash tables in memory only. The table is located within the Java virtual machine in which Access Manager runs—that is, on the server to which the users first logged in.

SSO functions in a session through the SSO Token, a domain cookie that contains the user's session ID.

For details on how to enable session failover, see Chapter 6, "Implementing Session Failover" in the Access Manager Postinallation Guide.

Q: How do I verify that a session is properly terminated after a logout?

In the Access Manager Administration Console, check the status of the user session by clicking the Sessions tab.

Also, if you have set debug=message on the Access Manager server, a message like the following is recorded in the amSession debug log after a session has terminated:

SESSION NOTIFICATION : ... uid of user state="destroyed"

Q: What are the MaxSessionTime and MaxIdleTime session parameters and their possible values?

MaxSessionTime is the maximum length of time in which an authenticated session remains valid. The value, which can be 1 minute or more, defaults to 120 minutes. Theoretically, MaxSessionTime can take a value up to 2 to the power 63 minus 1, but that would mean a never-ending session and hence weak security. You can set up the idle time such that the session expires after inactivity for a certain period of time. However, relying only on inactivity to terminate user sessions is a security risk.

MaxIdleTime is the length of time in which the session remains inactive before it expires—unless it does so on its own if MaxSessionTime is shorter than MaxIdleTime. It is recommended that you set the MaxSessionTime value to one that's higher than the value for MaxIdleTime and MaxIdleTime to a relatively low value.

The attribute syntax is number, which is represented as an integer in service management. number can take the maximum integer value—up to 2 to the power 31 minus 1, which is equal to 2147483647. That number (in minutes) is a large value. In the real world, session timeouts generally should never exceed a few hours.

Q: What is the difference between the max active sessions and max sessions in table settings in the /var/opt/SUNWam/debug/amSSO file?

max active sessions means the number of active user sessions and timed-out sessions. Timed-out sessions last longer, depending on the purge delay settings.

max sessions in table refers only to the number of active user sessions.

Q: What is the difference between the session notification mode and polling mode? How does that affect the refreshing of the session client cache?

The Notification Service enables session notifications to be sent to Web containers that run the Access Manager SDK remotely. The notifications apply only to the Session, Policy, and Naming Services. In addition, the remote application must be running in a Web container. The notifications accomplish the following:

Sync up the client side cache of the respective services.
Enable more real-time updates on the clients.

No changes on the client are required to support notifications.

Note: Notifications work only if the remote SDK is installed on a Web container.

Polling mode is an action triggered by the client. The session client maintains a background thread to periodically retrieve the states of all the sessions in the local session tables (cache).

If notification mode is enabled on the client side (Policy Agents or Access Manager's remote Java SDK), any session change on the server side triggers a notification to the client and Access Manager updates the client session cache immediately. On the contrary, if polling mode is enabled, Access Manager refreshes the session cache on the client side only after the next polling interval.

Q: What value should I set for com.iplanet.am.cookie.encode in the AMConfig.properties file? What are the implications of setting that value to true or false on both the client side and server side?

See "Disabling Cookie Encoding" in the Access Manager Postinstallation Guide.

Q: Where is the documentation regarding the session framework?

See Documents and Files: Architecture on OpenSSO.

Q: How do I resolve the UnsupportedOperationException error after creating an SSO Token with the SSOTokenManager(Principal principal, String password) method?

That method of creating SSO Tokens is no longer valid. Instead, use the regular LDAP authentication mechanism for policies, federation, and so forth. For details and code samples, see Chapter 2, using Authentication APIs and SPIs in the Access Manager Developer's Guide.

See this code example for creating an SSO Token.

Q: How do I resolve the Maximum Session Limit Reached error while attempting to log in to the Access Manager Administration Console?

Once Access Manager reaches the maximum session limit, only amadmin can log in to the Administration Console. In the AMConfig.properties file, the com.iplanet.am.session.maxSessions parameter controls the number of sessions allowed in Access Manager.

To diagnose the error, do either of the following:

Turn on the stats setting in the AMConfig.properties file, as follows:

com.iplanet.am.stats.interval=60 (one minute)
com.iplanet.services.stats.state=file

Afterward, view the output in the /var/opt/SUNWam/debug/amStats file, which shows the number of the current active sessions.

Q: After a user session times out, instead of a redirect to the login page, the session-timeout page is displayed. How do I resolve that error?

This is normal behavior, not an error. After a session timeout, if the purge delay time has not elapsed, the session stays in the session table in the timed-out stage. During that time, a session-timeout page is displayed. Once the purge delay time has elapsed, Access Manager deletes the session from the session table and redirects you to the login page.

You can modify the purge delay time (60 minutes by default) by changing the value of the com.iplanet.am.session.purgedelay parameter in the AMConfig.properties file. After a session times out, the purge delay time is the extended period for which the token resides in the Session Service. The session token is in INVALID state during this period. After this time period has elapsed, the session terminates. In addition, by means of the SSO APIs, the client application can use the value of this time period to check whether the session has timed out.