Implement single sign-on to minimize web user authentications

Implement single sign-on to minimize web user authentications

With single sign-on (SSO) support, web users can use LTPA tokens to authenticate once when accessing web resources across multiple WebSphere Application Servers in multiple cells in the same DNS domain. A cookie is created containing the LTPA token and inserted into the HTTP response. The cookie is sent in the request for WAS server resources in the domain. The LTPA token is extracted from the cookie and validated. If the request is between different cells of WASs, we must share LTPA keys and the user registry. The realm names on each system in the SSO domain are case sensitive and must match identically. For local OS, the realm name is the domain name if a domain is in use. In Windows, if a domain is not used, the realm name is the machine name. In UNIX, the realm name is the same as the host name. For the LDAP the realm name is the host:port realm name of the LDAP server. The LTPA authentication mechanism requires enabling SSO if any of the web applications have form login as the authentication method. Single sign-on is a subset of LTPA.
When security attribute propagation is enabled, a cookie is always added to the response

Token type Purpose How to specify
LtpaToken2 only Default token type. Uses the AES-CBC-PKCS5 padding encryption strength (128-bit key size). This token is stronger than the older LtpaToken used prior to WAS v6.02. This is the recommended option when interoperability with older releases is not necessary. Disable the Interoperability mode option in...
Security | Global security | Web security | Single sign-on (SSO)

LtpaToken and LtpaToken2 Use to interoperate with releases prior to WebSphere Application Server Version 5.1.1. The older LtpaToken cookie is present along with the new LtpaToken2 cookie. Provided the LTPA keys are correctly shared, you should be able to interoperate with any version of WebSphere using this option. Enable the Interoperability mode option
Security | Global security | Web security | Single sign-on (SSO)

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

Open the console.

http://localhost:port_number/ibm/console

Click...
Security | Global security | Web security Single sign-on (SSO)

Click the Enabled option if SSO is disabled.
After clicking the Enabled option, complete the remaining steps to enable security.

Click Requires SSL if all of the requests are expected to use HTTPS.

Enter the fully qualified domain names in the Domain name field where SSO is effective.
If we 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 valid only for the server that created the cookie.
When specified multiple domains, we can use the following delimiters: a semicolon (;), a space ( ), a comma (,), or a pipe (|).
WebSphere Application Server 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 specified 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.

Domain name value type Example Purpose
Blank
The domain is not set. This causes the browser to set the domain to the request host name. The sign-on is valid on that single host only.
Single domain name austin.ibm.com If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
UseDomainFromURL UseDomainFromURL If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
Multiple domain names austin.ibm.com;raleigh.ibm.com The sign-on is valid for all hosts within the domain of the request host name.
Cross-domain SSO is not supported. For example, chicago.xxx.com and cleveland.yyy.com where the DNS domains are different.
Multiple domain names and UseDomainFromURL austin.ibm.com;raleigh.ibm.com; UseDomainFromURL The sign-on is valid for all hosts within the domain of the request host name.
Cross-domain SSO is not supported. For example, chicago.xxx.com and cleveland.yyy.com where the DNS domains are different.

If we specify the UseDomainFromURL, WebSphere Application Server 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, WebSphere Application Server sets the SSO domain name value to raleigh.ibm.com .
The value, UseDomainFromURL, is case insensitive. We can type usedomainfromurl to use this value.
For more information, see Single sign-on settings.

Optional: Enable the Interoperability mode option to support SSO connections in WebSphere Application Server version 5.1.1 or later to interoperate with previous versions of the application server.
This option sets the old-style LtpaToken token into the response so it can be sent to other servers that work only with this token type. Otherwise, only the LtpaToken2 token is added to the response.
If performance is a consideration, and you are only connecting to Version 6.1 or later servers that and are not running products that depend on the LtpaToken, do not enable Interoperability mode. When Interoperability mode is not enabled, an LtpaToken is not returned in a response.

Optional: Enable the Web inbound security attribute propagation option if we 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.
Important: If the following statements are true, IBM recommends disabling 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 token using WSSecurityHelper APIs.
If 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 application servers.
The following two custom properties might help to improve performance when security attribute propagation is enabled:

com.ibm.CSI.propagateFirstCallerOnly
The default value of this property is true. When true the first caller in the propagation token that stays on the thread is logged when security attribute propagation is enabled. When false, all of the caller switches are logged, which can affect performance.

com.ibm.CSI.disablePropagationCallerList
When true the ability to add a caller or host list in the propagation token is completely disabled. This function is beneficial when the caller or host list in the propagation token is not needed in the environment.

Click OK.

What to do next

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

Subtopics

Single sign-on for HTTP requests using SPNEGO web authentication

Create a single sign-on for HTTP requests using SPNEGO Web authentication

Create a single sign-on for HTTP requests using the SPNEGO TAI (deprecated)

(iseries) Configure single sign-on capability with Enterprise Identity Mapping

Configure single sign-on capability with Tivoli Access Manager or WebSEAL

Related concepts
Web component security
LTPA
Security attribute propagation
Authenticating users
Enable security
Configure the Lightweight Third Party Authentication mechanism
Single sign-on configuration troubleshooting tips for security
Security: Resources for learning

Domain name value type	Example	Purpose
Blank		The domain is not set. This causes the browser to set the domain to the request host name. The sign-on is valid on that single host only.
Single domain name	austin.ibm.com	If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
UseDomainFromURL	UseDomainFromURL	If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
Multiple domain names	austin.ibm.com;raleigh.ibm.com	The sign-on is valid for all hosts within the domain of the request host name. Cross-domain SSO is not supported. For example, chicago.xxx.com and cleveland.yyy.com where the DNS domains are different.
Multiple domain names and UseDomainFromURL	austin.ibm.com;raleigh.ibm.com; UseDomainFromURL	The sign-on is valid for all hosts within the domain of the request host name. Cross-domain SSO is not supported. For example, chicago.xxx.com and cleveland.yyy.com where the DNS domains are different.