Sun Java System Messaging Server 6.3 Administration Guide

6.1 Access Manager SSO for Sun Java System Servers

This section describes SSO using Access Manager. It consists of the following sections:

6.1.1 SSO Limitations and Notices

The Messenger Express session is only valid for as long as the Access Manager session is valid. If the user logs out of Access Manager the webmail session is automatically closed (single sign-off).
SSO Applications working together must be in the same DNS domain. (Also known as cookie domain).
SSO Applications must have access to Access Manager verification URL (naming service).
Browsers must have cookies.

6.1.2 Configuring Messaging Server to Support SSO

Four configutil parameters support Messaging Server SSO. Of these four, only one, local.webmail.sso.amnamingurl is required to enable SSO with Messaging Server. To enable SSO, set this parameter to the URL where Access Manager runs the naming service. Typically this URL is http://server/amserver/namingservice. Example:

configutil -o local.webmail.sso.amnamingurl -v 
http://sca-walnut:88/amserver/namingservice

Note –

Access Manager SSO does not look at local.webmail.sso.enable which enables the older SSO mechanism. local.webmail.sso.enable should be left to off or unset otherwise warning messages will be logged about missing configuration parameters which are needed for the old SSO mechanism.

You can modify the SSO configuration parameters shown in Table 6–3, by using the configutil command.

Table 6–1 Access Manager Single Sign-On Parameters


Parameter	Description
local.webmail.sso.amnamingurl	The URL where Access Manager runs the naming service. Mandatory variable for single sign-on through Access Manager. Typically this URL is `http://server/amserver/namingservice.` Default: Not set.
local.webmail.sso.amcookiename	Access Manager cookie name. By default Access Manager saves its session handle in a cookie called `iPlanetDirectoryPro`. If it is configured to use another cookie name, then that name needs to be configured in Messaging Server as this parameter so that Messaging Server knows what to look for when doing single-sign on. Default value must not be changed if IS has default configuration. Default: `iPlanetDirectoryPro`
local.webmail.sso.amloglevel	AMSDK logging level. The SSO library used by Messaging Server has its own logging mechanism separate from Messaging Server. Its messages are logged in a file called `http_sso` under `msg-svr-base`/`log`. By default only messages with `info` or higher are logged, but it is possible to increase the logging level by setting the logging level to a value from 1 to 5 (1 = errors, 2 = warnings, 3 = info, 4 = debug, 5 = maxdebug). Be aware that the library doesn’t have the same notion of message importances as Messaging Server and that setting the level to `debug` can result in a lot of meaningless data. Also the `http_sso` log file is not managed by common Messaging Server logging code and is never cleaned up or rolled over. It is the responsibility of the system administrator to clean it up when setting the log level higher than the default. Default: 3
local.webmail.sso.singlesignoff	Single sign-off from Messaging Server to Access Manager. Access Manager is the central authentication authority, and single sign-off is always enabled from Access Manager to Messaging Server. This option allows a site to configure whether the logout button in webmail should also log the user out of Access Manager (saving some customization work). By default this is enabled. If this is disabled, a user logging out of the default webmail client is automatically logged back in since logout refers to the root document and the root document refers to the inbox display as long as the Access Manager cookie exists and is valid. Therefore, a site choosing to disable this option needs to customize what happens at webmail logout. Default: yes

6.1.3 Troubleshooting SSO

If there is a problem with SSO, the first thing to do is check the webmail log file msg-svr-base/log/http for errors. Increasing the logging level may be helpful (configutil -o logfile.http.loglevel -v debug). If this does not help, then check the amsdk messages in msg-svr-base/log/http_sso, then increase the amsdk logging level (configutil -o local.webmail.sso.amloglevel -v 5). Note that new logging levels only take effect after server restart.

If SSO is still having problems, make sure you are using fully qualified host names of both Access Manager and Messaging Server during log in. Cookies are only shared between servers of the same domain, and browsers do not know what the domain is for local server names, so one must use the fully qualified names in the browser for SSO to work.