Single sign-on settings


 

+

Search Tips   |   Advanced Search

 

To set the configuration values for SSO...


Parameters

Enabled

The single sign-on function is enabled.

Web apps that use J2EE FormLogin style login pages, such as the admin console, require 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

The single sign-on function is enabled only when requests are made over HTTPS SSL connections.

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

Domain name

Domain name (.ibm.com, for example) for all single sign-on hosts.

The appserver 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 app is running. Also, single sign-on is then restricted to the appserver host name and does not work with other appserver host names in the domain.

We 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 we specify ibm.com;mpls.setgetweb.com and a match is found in the ibm.com domain first, the appserver does not match the mpls.setgetweb.com domain. However, if a match is not found in either ibm.com or mpls.setgetweb.com, then the appserver does not set a domain for the LtpaToken cookie.

If specify the UseDomainFromURL value, the appserver sets the SSO domain name value to the domain of the host used in the Web address. For example, if an HTTP request comes from server1.raleigh.ibm.com, the appserver sets the SSO domain name value to raleigh.ibm.com.

The UseDomainFromURL value is case insensitive. We can type usedomainfromurl to use this value.

Data type: String

Interoperability mode

An interoperable cookie is sent to the browser to support back-level servers.

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

Enable Interoperability mode to support SSO connections in WAS v5.1.1 or later to interoperate with previous versions of the appserver. 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.

Web inbound security attribute propagation

When enabled, security attributes are propagated to front-end appservers.

When disabled, only the LtpaToken is used to log in and recreate the Subject from the user registry.

If the appserver is a member of a cluster and the cluster is configured with a data replication service domain, then propagation occurs.

If DRS is not configured, then the SSO token contains the originating server information, which the receiving server uses to contact the originating server using an MBean call to get the original serialized security attributes.




 

Related tasks

Set single sign-on capability with TAM or WebSEAL
Login module settings for JAAS
Internet Explorer Does Not Set a Cookie for Two-Letter Domains