Configure single signon

 

+

Search Tips   |   Advanced Search

 

Overview

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

SSO is supported only when 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 WAS process in the same 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 WAS, 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 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.

If you are using single signon between a WAS V 5.0.x or V 5.1 server and a WAS V 4.0.x appserver, specify an LDAP server port number in the administrative console by clicking...

Security | User registries | LDAP

Set the LDAP ports numbers to the same numerical value. For WAS v5.x+, the default value is 0.

When you enable security attribute propagation, the following cookies are added to the response:

LtpaToken

The LtpaToken is used for interoperating with previous releases of WAS. This token contains the authentication identity attribute only.

LtpaToken2

LtpaToken2 contains stronger encryption and enables you to add multiple attributes to the token. This token contains the authentication identity and additional information such as the attributes used for contacting the original login server and the unique cache key for looking up the Subject when considering more than just the identity in determining uniqueness.

Token type Purpose How to specify
LtpaToken only This token type is used for the same SSO behavior existing in WAS V 5.1 and previous releases. Also, this token type is interoperable with those previous releases. Disable the Web inbound security attribute propagation option located in the SSO configuration panel in the administrative console. To access this panel, go to...

Security | Authentication mechanisms | LTPA | Single signon (SSO)

LtpaToken2 only This token type is used for Web inbound security attribute propagation and uses the AES, CBC, PKCS5 padding encryption strength (128 bit key size). However, this token type is not interoperable with releases prior to WAS V 5.1.1. The token type allows for multiple attributes specified in the token (mostly containing information to contact the original login server). Enable the Web inbound security attribute propagation option in the SSO configuration panel within the administrative console. Disable the Interoperability mode option in the SSO configuration panel within the administrative console. To access this panel, go to...

Security | Authentication mechanisms | LTPA | Single signon (SSO)

LtpaToken and LtpaToken2 These tokens together support both of the previous two options. The token types are interoperable with releases prior to WAS V 5.1.1 because LtpaToken is present. The security attribute propagation function is enabled because the LtpaToken2 is present. Enable the Web inbound security attribute propagation option in the SSO configuration panel within the administrative console. Enable the Interoperability mode option in the SSO configuration panel within the administrative console. To access this panel, go to...

Security | Authentication mechanisms | LTPA | Single signon (SSO)

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

  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. 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 WAS 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. (Optional)   Enable the Interoperability mode option if you want to allow SSO connections in WAS version 5.1.1 to interoperate with previous versions of the appserver.This option sets the old-style LtpaToken into the response so it can be sent to other servers that only work with this token type. However, this option applies only when the Web inbound security attribute propagation option is enabled. In this case, both the LtpaToken and LtpaToken2 are added to the response. Otherwise, only the LtpaToken2 is added to the response. If the Web inbound security attribute propagation option is disabled, then only the LtpaToken is added to the response.

  7. (Optional)   Enable the Web inbound security attribute propagation option if you want information added during the login at a specific front-end server to propagate to other front-end servers. The SSO token does not contain any sensitive attributes, but does understand where the original login server exists in cases where it needs to contact that server to retrieve serialized information. It also contains the cache look up value for finding the serialized information in DynaCache, if both front-end servers are configured in the same DRS replication domain. For more information, see Security attribute propagation.

    Note: If the following statements are true, it is recommended that you disable the Web inbound security attribute propagation option for performance reasons:

    • You do not have any specific information added to the Subject during a login that cannot be obtained at a different front-end server.

    • You did not add custom attributes to the PropagationToken using WSSecurityHelper application programming interfaces (APIs).

    If you find you are missing custom information in the Subject, re-enable the Web inbound security attribute propagation option to see if the information is propagated successfully to other front-end appservers. If you disable SSO, but use a trust association interceptor instead, you might still need to enable the Web inbound security attribute propagation option if you want to retrieve the same Subject generated at different front-end servers.

  8. (Optional)   Enter the fully qualified domain names in the Domain name field where SSO is effective.The cookie is sent for all of the servers that are contained within the domains that you specify in this field. If you specify domain names, they must be fully qualified. If the domain name is not fully qualified, WAS does not set a domain name value for the LtpaToken cookie and SSO is only valid for the server that created the cookie.

    You can configure the Domain name field using any of the following values:

    Domain name value type Example
    Blank  
    Single domain name austin.ibm.com
    UseDomainFromURL UseDomainFromURL
    Multiple domain names austin.ibm.com;raleigh.ibm.com
    Multiple domain names and UseDomainFromURL

    • austin.ibm.com;raleigh.ibm.com
    • UseDomainFromURL


    If you specify the UseDomainFromURL value type, WAS sets the SSO domain name value to the domain of the host that makes the request. For example, if an HTTP request comes from server1.raleigh.ibm.com, WAS sets the SSO domain name value to raleigh.ibm.com.

    Tip: The value, UseDomainFromURL, is case insensitive. You can type usedomainfromurl to use this value.

    When you specify multiple domains, you can use the following delimiters: a semicolon (;), a space ( ), a comma (,), or a pipe (|). WAS searches the specified domains in order from left to right. Each domain is compared with the host name of the HTTP request until the first match is located. For example, if you specify ibm.com; austin.ibm.com and a match is found in the ibm.com domain first, WAS does not continue to search for a match in the austin.ibm.com domain. However, if a match is not found in either the ibm.com or austin.ibm.com domains, then WAS does not set a domain for the LtpaToken cookie.

  9. 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
Security attribute propagation
Related reference
Single signon settings
Security: Resources for learning