[V5.1.1 and later]Single signon settings

Use this page to set the configuration values for single signon (SSO).

To view this administrative console page, click Security > Authentication Mechanisms > LTPA > Single Signon (SSO).

 

Configuration tab

Requires SSL

Specifies that the single signon function is enabled only when requests are made over HTTPS Secure Sockets Layer (SSL) connections.

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

Domain Name

Specifies a fully qualified domain name (.ibm.com, for example) for all single signon hosts.

[V5.1]If no value is specified, the Web browser of the user defaults to the value of the host name where the Web application is running. This default restricts the HTTP cookie (generated for SSO purposes) only to the originating host. Restricting the HTTP cookie can be undesirable if there is more than one host is participating in the SSO domain. Leaving the domain name attribute empty is only desirable if multiple virtual hosts with different domain names are running on the same physical host. With this field empty, your Web browser can default the domain name to each different virtual host. If a domain name is explicitly specified in this field, then that value is used for all of the virtual hosts and restricts them to a single domain, which can be undesirable in some situations.

[V5.1]If a domain name is explicitly specified, then all of the Web pages used to access protected Web resources contain the server domain name service (DNS) host name. For example, after global security is configured for LTPA and an explicit SSO domain name is specified, then the administrative console is accessible with the following Web address: http://yourhost.austin.ibm.com:9090/admin, where yourhost.austin.ibm.com is replaced with your server DNS host name.

[V5.1.1 and later]If the domain name is not fully qualified, WebSphere Application Server does not set a domain name value for the LtpaToken cookie and SSO is only valid for the server that created the cookie.

[V5.1.1 and later]You can specify multiple domains separated by 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 you specify ibm.com;austin.ibm.com and a match is found in the ibm.com domain first, WebSphere Application server does not match the austin.ibm.com domain. However, if a match is not found in either the ibm.com or the austin.ibm.com domains, then WebSphere Application Server does not set a domain for the LtpaToken cookie.

[V5.1.1 and later]If you specify UseDomainFromURL, WebSphere Application Server sets the SSO domain name value to the domain of the host used in the URL. 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.

[V5.1.1 and later]Tip: The UseDomainFromURL value, is case insensitive. You can type usedomainfromurl to use this value.

Data type: String

Enabled

Specifies that the single signon function is enabled.

Web applications that use Java 2 Enterprise Edition (J2EE) FormLogin style login pages (such as the WebSphere Application Server administrative console) require single signon (SSO) enablement. Only disable SSO for certain advanced configurations where LTPA SSO-type cookies are not required.

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

Interoperability mode   [V5.1.1 and later]

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

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 signon (SSO) cookies back to the browser. In some cases, the server just sends the interoperable SSO cookie.

Web inbound security attribute propagation   [V5.1.1 and later]

When Web inbound security attribution propagation is enabled, security attributes are propagated to front-end appservers. When this option is disabled, the single signon (SSO) token is used to log in and recreate the Subject from the user registry. If you disable this option, the Web inbound login module functions the same as it did in previous releases.

If the appserver is a member of a cluster and the cluster is configured with a distributed 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.


Related reference
Administrative console buttons
Administrative console page features
Administrative console scope settings
Administrative console filter settings
Administrative console preference settings