Single sign-on settings

 

+

Search Tips   |   Advanced Search

 

To set the configuration values for SSO, from the console...

Security | Secure administration, applications, and infrastructure | Authentication | Web security | Single sign-on (SSO)

 

Configuration tab

Enabled

Specify that the single sign-on function is enabled.

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

Specify that 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

Specify the 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 application 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.

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 appserver does not match the austin.ibm.com domain.

If a match is not found in either ibm.com or austin.ibm.com, then the appserver does not set a domain for the LtpaToken cookie.

If you specify the UseDomainFromURL value, the appserver 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 appserver sets the SSO domain name value to...

raleigh.ibm.com

UseDomainFromURL is case insensitive. You 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 WebSphere Application Server, 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.

Web inbound security attribute propagation

When Web inbound security attribution propagation is enabled, security attributes are propagated to front-end appservers. When this option is disabled, the SSO token 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 (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

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

 

Related Reference

Login module settings for Java Authentication and Authorization Service

 

Reference topic