Single sign-on settings

Use this page to set the configuration values for single sign-on (SSO).

To view this administrative console page, complete the following steps:
  1. Click Security > Global security.
  2. Under Authentication, click Web and SIP security > Single sign-on (SSO).

The Set security cookies as HTTPOnly to resist cross-site scripting attacks check box has been added to the Single sign-on settings page for this release. The HttpOnly attribute is a browser attribute created to prevent client side applications (such as Java™ scripts) from accessing cookies to prevent some cross-site scripting vulnerabilities. The attribute specifies that LTPA and WASReqURL cookies include the HTTPOnly field.

Enabled

Specifies that the single sign-on function is enabled.

Web applications that use Java EE FormLogin style login pages, such as the administrative console, require single sign-on (SSO) enablement. Only disable SSO for certain advanced configurations where LTPA SSO-type cookies are not required.

Information Value
Data type: Boolean
Default: Enabled
Range: Enabled or Disabled

Requires SSL

Specifies that the single sign-on function is enabled only when requests are made over HTTPS Secure Sockets Layer (SSL) connections. When this property is enabled, security is automatically enabled.

Information Value
Data type: Boolean
Default: Disable
Range: Enable or Disable

Domain name

Specifies the domain name (such as ibm.com or .ibm.com) for all single sign-on hosts.

The application server uses all the information after the first period, from left to right, for the domain names. If this field is not defined, the web browser defaults the domain name to the host name where the web application is running. Also, single sign-on is then restricted to the application server host name and does not work with other application server host names in the domain.

You can specify multiple domains separated by a semicolon (;), a space ( ), a comma (,), or a pipe (|). 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, the application server does not match the austin.ibm.com domain. However, if a match is not found in either ibm.com or austin.ibm.com, then the application server does not set a domain for the LtpaToken cookie.

Avoid trouble:
  • The session manager uses a secure random generator to generate session ID. The session ID is written to the cookie when the cookie is created in the setCookie method. The session manager does not set the LtpaToken to cookies.
  • Usage of multiple domain names in the Domain Name field does not necessarily enable you to use different domain names during a single session. For example, if a Domain Name contains the value ibm.com;lotus.com, you can only access a server with a successful SSO login at www.ibm.com or www.lotus.com but not both because the browser controls whether or not to send the LTPA cookie.

If you specify the UseDomainFromURL value, the application server sets the SSO domain name value to the domain of the host that is used in the web address. For example, if an HTTP request comes from server1.raleigh.ibm.com, the application server sets the SSO domain name value to raleigh.ibm.com.

Tip: The UseDomainFromURL value is case insensitive. You can type usedomainfromurl to use this value.
Information Value
Data type: String

Interoperability mode

Specifies that an interoperable cookie is sent to the browser to support back-level servers.

In WebSphere® Application Server Version 6 and later, a new cookie format is needed by the security attribute propagation functionality. When the interoperability mode flag is enabled, the server can send a maximum of two single sign-on (SSO) cookies back to the browser. In some cases, the server just sends the interoperable SSO cookie.

Web inbound security attribute propagation

When web inbound security attribute propagation is enabled, security attributes are propagated to front-end application servers. When this option is disabled, the single sign-on (SSO) token is used to log in and recreate the Subject from the user registry.

If the application server is a member of a cluster and the cluster is configured with a data replication service (DRS) domain, then propagation occurs. If DRS is not configured, then the SSO token contains the originating server information.

With this information, the receiving server can contact the originating server using an MBean call to get the original serialized security attributes.

Set security cookies as HTTPOnly to resist cross-site scripting attacks

The HttpOnly attribute is a browser attribute created to prevent client side applications (such as Java scripts) from accessing cookies to prevent some cross-site scripting vulnerabilities. The attribute specifies that LTPA and WASReqURL cookies include the HTTPOnly field.

For session cookies, see the session settings for servers, applications, and web modules.

Information Value
Data type: boolean
Default: enabled
Range: enabled or disabled

LTPA V2 cookie name

Use this field to set the new com.ibm.websphere.security.customLTPACookieName and com.ibm.websphere.security.customSSOCookieName custom properties.

The com.ibm.websphere.security.customLTPACookieName custom property is used to customize the name of the cookies used for Lightweight Third Party Authentication (LTPA) tokens.

The com.ibm.websphere.security.customSSOCookieName custom property us used to customize the name of the cookies used for Lightweight Third Party Authentication Version 2 (LTPA2) tokens.

For more detailed information on each property, read the Security custom properties topic.