Configuring SSO Through Access Manager
Sun Java Enterprise System servers, including Calendar Server and Messaging
Server, can implement SSO using Sun Java System Access Manager (release 6 2003Q4 or
later)
Access Manager serves as the SSO gateway for Sun Java Enterprise System servers.
That is, users log in to Access Manager and then can access other Sun Java Enterprise
System servers, as long as the servers are configured properly for SSO.
To use SSO with Calendar Server
-
Make sure that Access Manager and Directory Server are installed and configured.
For information about installing and configuring these products, refer to the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
-
Configure SSO for Calendar Server by setting the parameters shown in Configuring SSO Through Access Manager and then restarting
Calendar Server for the values to take effect. If necessary, remove the comment character
(!) when you set each parameter.
Note –
When you set the local.calendar.sso.amnamingurl parameter,
you must use a fully qualified name for Access Manager.
-
To configure SSO for Messaging Server, refer to the Sun Java System Messaging Server 6 2005Q4 Administration Guide.
-
Users log into Access Manager using their Directory Server LDAP user name
and password. (A user who logs in through another server such as Calendar Server or
Messaging Server will not be able to use SSO to access the other Sun Java Enterprise
System servers.)
-
After logging in, users can access Calendar Server through Communications
Express using the appropriate URL. Users can also access other Sun Java Enterprise
System servers such as Messaging Server, if the servers are configured properly for
SSO.
Parameter
|
Description
|
local.calendar.sso.amnamingurl
|
Specifies the URL of the Access Manager SSO naming service.
Default is
"http://AccessManager:port/amserver
/namingservice"
where AccessManager is the fully qualified
name of Access Manager, and port is the Access
Manager port number.
|
local.calendar.sso.amcookiename
|
Specifies the name of the Access Manager SSO cookie.
Default is "iPlanetDirectoryPro".
|
local.calendar.sso.amloglevel
|
Specifies the log level for Access Manager SSO. Range is from 1 (quiet) to 5
(verbose). Default is “3“.
|
local.calendar.sso.logname
|
Specifies the name of the Access Manager SSO API log file.
Default is: “am_sso.log”
|
local.calendar.sso.singlesignoff
|
Enables (“yes“) or disables (“no“) single sign-off from
Calendar Server to Access Manager.
If enabled, a user who logs out of Calendar Server is also logged out of Access
Manager, and any other sessions the user had initiated through Access Manager (such
as a Messaging Server Webmail session) are terminated.
Because Access Manager is the authentication gateway, single sign-off is always
enabled from Access Manager to Calendar Server.
Default is “yes“.
|
Considerations for Using SSO With Access Manager
-
A calendar session is valid only as long as the Access Manager session
is valid. If a user logs out of Access Manager, the calendar session is automatically
closed (single sign-off).
-
SSO applications must be in the same domain.
-
SSO applications must have access to the Access Manager verification
URL (naming service).
-
Browsers must support cookies.
-
If you are using the Sun Java System Portal Server gateway, set the
following Calendar Server parameters:
Configuring SSO Through Communications Servers Trusted Circle
Technology
When configuring SSO through Communications Servers trusted circle technology
(that is, not through Access Manager), consider these points:
-
Each trusted application must be configured for SSO.
-
SSO does not work correctly if the default.html page
is in your browser’s cache. Before using SSO, be sure to reload the default.html page in your browser. For example, in Netscape Navigator, hold
down the Shift key and then click Reload.
-
SSO works only for bare URL's. For example, SSO works for:http://servername.
The following table describes the Calendar Server configuration parameters for
SSO through Communications Servers trusted circle technology.
Table 9–1 Calendar
Server SSO Parameters Through Communications Servers Trusted Circle Technology
Parameter
|
Description
|
sso.enable
|
This parameter must be set to "1" (the default) to enable SSO. "0" disables
SSO.
|
sso.appid
|
This parameter specifies the unique application ID for the specific Calendar
Server installation. Each trusted application must also have a unique application
ID. The default is: "ics50"
|
sso.appprefix
|
This parameter specifies the prefix value to be used for formatting SSO cookies.
The same value must be used by all trusted applications, because only SSO cookies
with this prefix will be recognized by Calendar Server. The default is: "ssogrp1"
|
sso.cookiedomain
|
This parameter causes the browser to send a cookie only to servers in the specified
domain. The value must begin with a period (.)
|
sso.singlesignoff
|
A value of “true” (the default) clears all SSO
cookies on the client with prefix values matching the value configured in sso.appprefix
when the client logs out.
|
sso.userdomain
|
This parameter sets the domain used as part of the user's SSO authentication.
|
sso.appid.url = "verifyurl"
|
This parameter sets the verify URL values for peer SSO hosts for the Calendar
Server configuration. One parameter is required for each trusted peer SSO host. The
parameter includes the:
-
Application ID (appid) identifies each
peer SSO host whose SSO cookies are to be honored
-
Verify URL (verifyurl) includes the host
URL, host port number, and VerifySSO? (including the ending question
mark (?).
In this example, the Calendar Server application
ID is ics50, the host URL is sesta.com, and
the port is 8883.
The Messenger Express application
ID is msg50, the host URL is sesta.com, and
the port is 8882.
For example:
sso.ics50.url=
"http://sesta.com:8883
/VerifySSO?"
sso.msg50.url=
"http://sesta.com:8882
/VerifySSO?"
|
The following table describes the Messaging Server configuration parameters
for SSO through Communications Servers trusted circle technology.
Table 9–2 Messaging
Server SSO Parameters Through Communications Servers Trusted Circle Technology
Parameter
|
Description
|
local.webmail.sso.enable
|
This parameter must be set to a non-zero value to enable SSO.
|
local.webmail.sso.prefix
|
This parameter specifies a prefix used when formatting SSO cookies set by the
HTTP server. For example: ssogrp1
|
local.webmail.sso.id
|
This parameter specifies the unique application ID ( for example: msg50) for the Messaging Server.
Each trusted application must also have a unique application ID.
|
local.webmail.sso.cookiedomain
|
This parameter specifies the cookie domain value of all SSO cookies set by the
HTTP server.
|
local.webmail.sso.singlesignoff
|
A non-zero value clears all SSO cookies on the client with prefix values matching
the value configured in local.webmail.sso.prefix when the client
logs out.
|
local.sso.appid.url=verifyurl
|
This parameter sets the verify URL values for peer SSO hosts for the Messaging
Server configuration. One parameter is required for each trusted peer SSO host. The
parameter includes these items:
-
Application ID (appid) identifies each
peer SSO host whose SSO cookies are to be honored
-
Verify URL (verifyurl) includes the host
URL, host port number, and VerifySSO? (including the ending ?).
For example:
local.sso.ics50.verifyurl=
http://sesta.com:8883/VerifySSO?
In this example, the Calendar Server application ID is ics50, the
host URL is sesta.com, and the port is 8883.
local.sso.msg50.verifyurl=
http://sesta.com:8882/VerifySSO?
In this example, the Messaging Server application ID is msg50, the host URL is sesta.com, and the port is 8882.
|
For more information about configuring Messaging Server for SSO, see the Sun Java System Messaging Server 6 2005Q4 Administration Guide.