Sun logo      Previous      Contents      Index      Next     

Sun Java Enterprise System 2003Q4 Installation Guide

Chapter 13
Configuring Single Sign-on

This chapter describes how to configure single sign-on (SSO) after finishing the installation process.

This chapter contains the following sections:

Overview of SSO in Java Enterprise System

SSO is the ability for a Java Enterprise System user to log on once with user ID and password and have access to multiple Sun ONE component product applications.

When you are using built-in Java Enterprise System services, Identity Server 6.1 is the official gateway used for SSO. That is, users must log into Identity Server 6.1 to get access to other SSO configured servers. For more information on Identity Server 6.1 SSO, refer to Chapter 4, “Single Sign-on and Sessions,” in the Sun ONE Identity Server 6.1 Customization and API Guide (http://docs.sun.com/doc/816-6774-10).

SSO in Java Enterprise System is divided into three types:

This chapter focuses on describing how to configure built-in Java Enterprise System services to operate with SSO. This kind of SSO is also referred to in this chapter as Identity Server 6.1 SSO.

For in-house developed services on supported application servers, see the following documentation for more information:

For in-house developed applications, either Java or non-Java, see the following documentation for more information:

Policy Agents

Two types of policy agents are supported by Identity Server: the web agent and the J2EE/Java agent. The web agent enforces URL-based policy while the J2EE/Java agent enforces J2EE-based security and policy.

Both types are available for installation separately from Identity Server and can be downloaded from:

http://wwws.sun.com/software/download/inter_ecom.html

Using SSO in Calendar Server and Messaging Server

Consider the following when configuring SSO for Calendar Server and Messaging Server:

Configuring Messaging Server and Calendar Server to Support SSO

The two ways of configuring Messaging Server and Calendar Server to use SSO are:

Using a trusted circle is the legacy method of implementing SSO. Though this method provides some features not available with Identity Server SSO, avoid using it, as all future development will be with the Identity Server.

The following procedure describes the method of using Identity Server 6.1. See the Sun ONE Messaging Server 6.0 Administrator’s Guide (http://docs.sun.com/doc/816-6738-10) and the Sun ONE Calendar Server 6.0 Administrator’s Guide (http://docs.sun.com/doc/816-6708-10) for information on trusted circle SSO.

    To Configure Messaging Server to Support SSO
  1. Use the following configutil commands to set these four SSO parameters for Messaging Server. 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 Identity Server runs the naming service.

    2. ./configutil -o local.webmail.sso.amnamingurl -v http://host:port/amserver/namingservice

    ./configutil -o local.webmail.sso.amcookie -v iPlanetDirectoryPro

    ./configutil -o local.webmail.sso.singlesignoff -v 1

    ./configutil -o service.http.ipsecurity -v no

    The following table explains these SSO parameters.

    Table 13-1  Messaging Server SSO Parameters 

    Parameter

    Description

    local.webmail.sso.amnamingurl

    Specifies the URL of the Identity Server SSO naming service.

    Default is http://IdentityServer:port/amserver/namingservice

    where IdentityServer is the fully qualified name of Identity Server, and port is the Identity Server port number.

    local.webmail.sso.amcookie

    Identity Server cookie name. If Identity Server is configured to use another cookie name, then that name needs to be configured in Messaging Server as local.webmail.sso.amcookiename, so that component products know what to look for when doing SSO. Default value is iPlanetDirectoryPro and must not be changed if Identity Server has default config.

    Default: iPlanetDirectoryPro

    local.webmail.sso.singlesignoff

    Enables ("yes") or disables ("no") single sign-off from Messaging Server to Identity Server.

    If enabled, a user who logs out of Messaging Server is also logged out of Identity Server, and any other sessions the user had initiated through Identity Server are terminated.

    Because Identity Server is the authentication gateway, single sign-off is always enabled from Identity Server to Messaging Server.

    Default: yes

    service.http.ipsecurity

    Sets whether or not to restrict session access to login IP addresses. If set to yes, when the user logs in, the server remembers which IP address the user used to log in. Then it only allows that IP address to use the session cookie it issues to the user.

    Default: yes

  2. Restart Messaging Server.
  3. If you need to configure proxy authentication, see "Configuring Proxy Authentication".
    To Configure Calendar Server to Support SSO
  1. For Calendar Server, edit the following parameters in the cal_svr_base/etc/opt/SUNWics5/config/ics.conf file:

    2. local.calendar.sso.amnamingurl="http://host:port/amserver/namingservice"

    local.calendar.sso.amcoookiename="iPlanetDirectoryPro"

    local.calendar.sso.logname="am_sso.log"

    local.calendar.sso.singlesignoff="yes"

    service.http.ipsecurity="no"

    render.xslonclient.enable="no"

    The following table explains the Calendar Server SSO parameters.

    Table 13-2  Calendar Server SSO Parameters 

    Parameter

    Description

    local.calendar.sso.amnamingurl

    Specifies the URL of the Identity Server SSO naming service.

    Default is http://IdentityServer:port/amserver/namingservice

    where IdentityServer is the fully qualified name of Identity Server, and port is the Identity Server port number.

    local.calendar.sso.amcoookiename

    Identity Server cookie name. If Identity Server is configured to use another cookie name, then that name needs to be configured in Calendar Server as local.calendar.sso.amcookiename, so that component products know what to look for when doing SSO. Default value is iPlanetDirectoryPro and must not be changed if Identity Server has default config.

    Default: iPlanetDirectoryPro

    local.calendar.sso.singlesignoff

    Enables ("yes") or disables ("no") single sign-off from Calendar Server to Identity Server.

    If enabled, a user who logs out of Calendar Server is also logged out of Identity Server, and any other sessions the user had initiated through Identity Server are terminated.

    Because Identity Server is the authentication gateway, single sign-off is always enabled from Identity Server to Calendar Server.

    Default: yes

    service.http.ipsecurity

    Sets whether or not to restrict session access to login IP addresses. If set to yes, when the user logs in, the server remembers which IP address the user used to log in. Then it only allows that IP address to use the session cookie it issues to the user.

    Default: yes

    render.xslonclient.enable

    Controls client-side rendering (currently for Internet Explorer 6.0 or later only). By default this parameter is set to "yes". To turn off client-side rendering, set the parameter to "no" and then restart Calender Server.

    Note: Set this parameter to "no" to disable style sheets for Internet Explorer, otherwise, Calendar Server won’t work through Identity Server.

  2. Restart Calendar Server.
  3. If you need to configure proxy authentication, see "Configuring Proxy Authentication".
    To Configure Instant Messaging to Support SSO

Instant Messaging supports Identity Server SSO “out of the box.” During the configuration portion of the Instant Messaging installation, the configurator asks whether the deployment will take advantage of SSO. The specific question is whether the Identity Server SDK is found on the system by the configurator.

The following table shows the SSO parameters in the ims_svr_base/SUNWiim/iim.conf file for Instant Messaging.

Table 13-3  Instant Messaging SSO Parameters 

Parameter

Description

Values

iim_server.usesso

This parameter tells the server whether or not to depend on the SSO provider during authentication. An SSO provider is a module which the server uses to validate a session ID with an SSO service.

In a portal deployment, the Portal Server Session API provides the Instant Messaging with the ability to validate session IDs sent by the client.

The iim_server.usesso parameter is used in conjunction with the iim_server.ssoprovider parameter.

The value for this parameter can either be 0, 1,or -1.

0 - Do not use the SSO provider (default).

1 - Use the SSO provider first and default to LDAP when the SSO validation fails.

-1- Use SSO provider only without attempting LDAP authentication even when the SSO validation fails.

iim_server.sso.update

Defines whether or not to enable session termination and expiration.

Can be true or false.

iim_server.ssoprovider

This parameter specifies the class implementing the SSO Provider. If iim_server.usesso is not equal to 0 and this option is not set, the server uses the default Portal Server based SSO Provider. (See the Instant Messaging API documentation for more information.)

Class name of the SSOProvider implementation.

See Appendix A, “Instant Messaging Configuration Parameters,” of the Sun ONE Instant Messaging 6.1 Administrator’s Guide (http://docs.sun.com/doc/817-4113-10) for more information.

    To Verify SSO for Messaging Server, Calendar Server, and Instant Messaging
  1. Log in as a valid user to the portal Desktop.
  2. In the browser, type the URL of the Messaging Server.

    3. You should not be prompted to log in to the Messaging Server.

  3. In the browser, type the URL of the Calendar Server.

    4. You should not be prompted to log in to the Calendar Server.

  4. Invoke the Instant Messenger client, either through the portal Desktop or by typing the URL of the Instant Messaging server in the browser.

    5. You should not be prompted to log in to Instant Messaging.

    To Troubleshoot SSO
  1. If there is a problem with SSO, first check the webmail log file, msg_svr_base/log/http, for errors.
  2. Increase the logging level:

    3. configutil -o logfile.http.loglevel -v debug

  3. Check the amsdk messages in the msg_svr_base/log/http_sso file, then increase the amsdk logging level:

    4. configutil -o local.webmail.sso.amloglevel -v 5

    The new logging levels only take effect after server restart.

  4. Make sure you are using fully qualified host names for both Identity Server and Messaging Server during log in. Because ookies are only shared between servers of the same domain, and browsers do not know what the domain is for local server names, you must use the fully qualified names in the browser for SSO to work.

Configuring SSO for Portal Mail and Calendar Channels

Portal Server provides both Mail and Calendar channels specifically designed for Messaging Server and Calendar Server. To render both mail and calendar content on the same portal Desktop, these channels connect to their respective back-end services and retrieve the relevant information with each Desktop reload.

Both channels leverage preexisting Portal Server, Messaging Server, and Calendar Server SSO features known as the SSO Adapter service and proxy authentication. The SSO Adapter service is derived from Identity Server and Portal Server. Proxy authentication is a feature of both Messaging Server and Calendar Server.

SSO Adapter Service

In previous releases of Portal Server, portal channels achieved SSO through their own mechanism. The underlying implementation is based on the Identity Server SSO Adapter service, which you must configure for each channel through the Identity Server console. This legacy portal channel SSO mechanism is only required when using Portal Server channels.

Note

The SSO Adapter service implementation currently supports only Portal Server. Do not confuse SSO Adapter service with Identity Server 6.1 SSO.

The SSO Adapter service enables end users to use applications, such as a Portal Server provider or any other web application, to gain authenticated access to various resource servers after signing in once. The resource servers that can be accessed depend on the implementations of the SSO Adapter interface that are available in the system.

Currently, Portal Server provides SSO Adapters for the following resource servers: Address Book, Calendar, and Mail.

Overview of Proxy Authentication

Proxy authentication requires a proxy user account, which acts as a trusted agent on behalf of users. The proxy users in Messaging Server and Calendar Server exist to provide end-user authentication without the need for end-user passwords.

The current Messaging Server and Calendar Server channels use the SSO Adapter service for Portal Server to authenticate against their respective back-end servers. By registering the proxy user’s name and password with the Portal Server Mail and Calendar channel SSO Adapter templates, users do not need to provide user names and passwords.

You must define proxy users must for both Messaging Server and Calendar Server for this to function.

The following figure shows how the SSO Adapter service uses proxy authentication with Calendar Server.

Figure 13-1  SSO Adapter Services Using Proxy Authentication

This figure represents how the SSO Adapter service uses proxy authentication with Calendar Server.

In the above figure:

  1. The user logs in to the Portal Server Desktop.
  2. The Desktop Calendar channel authenticates against Calendar Server. The proxy user authenticates on behalf of the user.
  3. The proxy user retrieves the user’s calendar information, on behalf of the user.
  4. The Calendar channel renders the information in HTML and returns it to the Desktop.

You need proxy authentication and SSO Adapter service configuration only for the Mail and Calendar portal channels. Neither proxy authentication nor SSO Adapter service is a replacement for the new Identity Server 6.1 SSO mechanism. You must enable Identity Server 6.1 SSO in both Messaging Server and Calendar Server for system-wide SSO to work properly.

The following figure shows the full relationship between Identity Server 6.1 SSO and the Portal Server channel SSO mechanism.

Figure 13-2  Identity Server SSO and Portal Server Channel SSO Mechanism

This figure represents the Identity Server SSO and Portal Server channel SSO mechanism.

In the above figure:

The following figure shows an example using the Calendar channel.

Figure 13-3  Identity Server SSO and Calendar Channel Communication

This figure represents the Identity Server SSO and Calendar Channel communication.

In the above figure:

  1. The user completes authentication with Identity Server.
  2. The user accesses the portal Desktop with an Identity Server cookie.
    1. Portal Server validates the cookie with Identity Server.
  3. The Calendar channel requests calendar content.
    • Proxy credentials are read from the SSO Adapter configuration template.
    • The proxy user performs authentication on behalf of the user.
  4. Desktop content is returned, including the rendered Calendar channel.
  5. The user accesses Calendar Server. Calendar Server verifies the Identity session cookie against the Identity Server. Identity Server validates the session cookie and provides the proper user information to start a Calendar session.

Configuring Proxy Authentication

To configure proxy authentication for the Calendar and Mail channels, you need to access the SSO Adapter Templates through the Identity Server console and you need to access the Sun ONE communication servers. Configuring proxy authentication involves:

    To Edit SSO Adapter Templates

For the specific instructions to perform this procedure, refer to Chapter 13, “Configuring the Communication Channels,” of the Sun ONE Portal Server 6.2 Administrator’s Guide (http://docs.sun.com/doc/816-6748-10).

    To Configure Proxy Authentication for Messaging Server and Calendar Server in Portal Server
  1. For Messaging Server, change to the ms_svr_base/sbin directory. For example:

    2. cd /opt/SUNWmsgsr/sbin

  2. Verify that the store.admin file contains admin:

    3. ./configutil -o store.admins

  3. Type the following:

    4. ./configutil -o service.http.allowadminproxy -v yes

  4. Restart the Messaging Server.
  5. For Calendar Server, edit the cal_svr_base/etc/opt/SUNWics5/config/ics.conf file:

    6. <Uncomment and modify the following parameter:>

    service.http.allowadminproxy=”yes”

    <Verify that these parameters are set correctly:>

    service.admin.calmaster.userid=”calmaster”

    service.admin.calmaster.cred=”password”

  6. Restart Calendar Server.
    To Verify Proxy Authentication

Use this procedure to verify that the Calendar and Messaging channels functional correctly from the Portal Server Desktop:

  1. Log in as a valid user to the portal Desktop.
  2. Examine the Calendar and Messaging channels.

    3. They should display the appropriate information.

  3. Customize the Calendar channel for better display.

    4. Select Edit Channel Display Options and change the Calendar View from Daily to Weekly to Weekly.



Previous      Contents      Index      Next     

Copyright 2003 Sun Microsystems, Inc. All rights reserved.