Configuring single signon

Before you begin

With single signon (SSO) support, Web users can authenticate once when accessing Web resources across multiple WebSphere Application Servers. Form login mechanisms for Web applications require that SSO is enabled.

SSO is supported only when Lightweight Third Party Authentication (LTPA) is the authentication mechanism.

When SSO is enabled, a cookie is created containing the LTPA token and inserted into the HTTP response. When the user accesses other Web resources in any other WebSphere Application Server process in the same domain name service (DNS) domain, the cookie is sent in the request. The LTPA token is then extracted from the cookie and validated. If the request is between different cells of WebSphere Application Servers, you must share the LTPA keys and the user registry between the cells for SSO to work.

The realm names on each system in the SSO domain are case sensitive and must match identically. For local OS on the Windows platform, the realm name is the domain name if a domain is in use or the machine name. On the Linux or UNIX platforms, the release name is the same as the host name. For the Lightweight Directory Access Protocol (LDAP), the realm name is the host:port realm of the LDAP server.

The LTPA authentication mechanism requires that you enable SSO if any of the Web applications have form login as the authentication method.

[5.0 only][Version 5.0.1][Version 5.0.2]If you are using single signon between a WebSphere Application Server Version 5.0.x or Version 5.1 server and a WebSphere Application Server Version 4.0.x application server, you must specify an LDAP server port number in the administrative console by clicking Security > User registries > LDAP. You must set the LDAP ports numbers to the same numerical value because for WebSphere Application Server Version 5.0.x or Version 5.1, the default value is 0, for WebSphere Application Server Version 4.0.x, the default value for the port is not 0. This situation is fixed with APAR PQ86930.

Why and when to perform this task

The following steps are required to configure SSO for the first time.

Steps for this task

  1. Access the administrative console by typing http://localhost:9090/admin in a Web browser.
  2. Click Security > Authentication mechanisms > LTPA in the Navigation panel on the left. Click Single Signon (SSO) in the Additional Properties section.
  3. Click Enable, if SSO is disabled.
    After you click Enable, make sure that you complete the remaining steps to enable security.
  4. Enable the Requires SSL field if all of the requests are expected on HTTPS.
  5. [5.0 only][Version 5.0.1][Version 5.0.2]Enter the domain name in the Domain name field where SSO is effective.
    The cookie is sent for all of the servers in this domain only. For example, if the domain is ibm.com, SSO works between the domains austin.ibm.com, raleigh.ibm.com and not austin.otherCompany.com.

    The Domain name field is optional, and, if left blank, the Web browser defaults to the domain name of the SSO cookie to the WebSphere Application Server that created it. In this case, SSO is only valid for the server that created the cookie. This behavior might be desirable when multiple virtual hosts are defined and need to have a separate domain specified in the SSO cookie.

  6. Click OK.

What to do next

For the changes to take effect, save, stop, and restart all the product servers (deployment managers, nodes and Application Servers).


Related concepts
Web component security
Related reference
Single signon settings
Security: Resources for learning



Searchable topic ID:   tsecmsso
Last updated: Jun 21, 2007 4:55:42 PM CDT    WebSphere Application Server Network Deployment, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/tsec_msso.html

Library | Support | Terms of Use | Feedback