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.