What is sso in java
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
The following table explains these 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 |
To Configure Calendar Server to Support SSO
The following table explains the 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. |
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.
| 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
You should not be prompted to log in to the Messaging Server.
You should not be prompted to log in to the Calendar Server.
To Troubleshoot SSO
configutil -o logfile.http.loglevel -v debug
configutil -o local.webmail.sso.amloglevel -v 5
The new logging levels only take effect after server restart.
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
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
The following figure shows an example using the Calendar channel.
Figure 13-3 Identity Server SSO and Calendar Channel Communication