Single signon settings

 

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 mechanisms, click LTPA.

  3. Under Additional properties, click Single sign-on (SSO).

Configuration tab

Enabled

That the single sign-on function is enabled.

Web applications that use J2EE 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.

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

Requires SSL

That the single sign-on 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

The domain name (.ibm.com, for example) 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.

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.

Data type: String

Interoperability mode

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 attribution 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 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 tasks


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

Related reference
Login module settings for Java Authentication and Authorization Service