Implement single sign-on to minimize Web user authentications

Implement single sign-on to minimize Web user authentications

+
Search Tips | Advanced Search

With single sign-on (SSO) support, Web users can authenticate once when accessing Web resources across multiple application servers. Form login mechanisms for Web applications require that SSO is enabled.
SSO is supported only when LTPA is the authentication mechanism.
When SSO is enabled, a cookie is created containing the LTPA token and inserted into the HTTP response. When the user accesses other Web resources in any other WAS process in the same DNS domain, the cookie is sent in the request. The LTPA token is then extracted from the cookie and validated. If the request is between different cells of application servers, share the LTPA keys and the user registry between the cells for SSO to work. The realm names on each system in the SSO domain are case sensitive and must match identically.
On Windows, for local OS, the realm name is the domain name if a domain is in use. If a domain is not used, the realm name is the machine name.
On *nix systems, the realm name is the same as the host name.
For the LDAP the realm name is the host:port realm name of the LDAP server.
When you enable security attribute propagation, the following cookies are added to the response:

LtpaToken

Used for inter-operating with previous releases of WAS. This token contains the authentication identity attribute only.

LtpaToken2

Contains stronger encryption and enables you to add multiple attributes to the token. This token contains the authentication identity and additional information such as the attributes that are used for contacting the original login server and the unique cache key for looking up the Subject when considering more than just the identity in determining uniqueness.

LtpaToken is generated for releases prior to WAS V5.1.1. LtpaToken2 is generated for WAS V5.1.1 and beyond.

Token type Purpose To specify

LtpaToken only Used for the same SSO behavior existing in WAS V5.1 and previous releases Disable the Web inbound security attribute propagation option, located in...
Security | Secure administration, applications, and infrastructure | Web security | SSO

LtpaToken2 only Used for Web inbound security attribute propagation and uses the AES, CBC, PKCS5 padding encryption strength (128-bit key size). Not interoperable with releases prior to WAS V5.1.1. The token type supports multiple attributes that are specified in the token, mostly containing information to contact the original login server. Enable the Web inbound security attribute propagation option in the SSO configuration panel within the administrative console. Disable the Interoperability mode option in the SSO configuration panel within the administrative console.
Security | Secure administration, applications, and infrastructure | Web security | Single sign-on (SSO)

LtpaToken and LtpaToken2 These tokens together support both of the previous two options. The token types are interoperable with releases prior to WAS V5.1.1 because LtpaToken is present. The security attribute propagation function is enabled because the LtpaToken2 is present. Enable the Web inbound security attribute propagation and Interoperability mode options in...
Security | Secure administration, applications, and infrastructure | Web security | Single sign-on (SSO)

To configure SSO for the first time

From the administrative console...
http://localhost:port_number/ibm/console

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

Click the Enabled option if SSO is disabled.
Click Requires SSL if all of the requests are expected to use HTTPS.
Enter the fully qualified domain names in the Domain name field where SSO is effective.
If you specify domain names, they must be fully qualified. If the domain name is not fully qualified, WAS does not set a domain name value for the LtpaToken cookie and SSO is valid only for the server that created the cookie.
When you specify multiple domains, you can use the following delimiters: a semicolon (;), a space ( ), a comma (,), or a pipe (|). WAS 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, WAS does not continue to search for a match in the austin.ibm.com domain. However, if a match is not found in either the ibm.com or austin.ibm.com domains, then WAS does not set a domain for the LtpaToken cookie.
You can configure the Domain name field using any of the following values:

Domain name value type Example Purpose
Blank The domain is not set. This causes the browser to set the domain to the request host name. The sign-on is valid on that single host only.
Single domain name austin.ibm.com If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
UseDomainFromURL UseDomainFromURL If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
Multiple domain names austin.ibm.com;raleigh.ibm.com The sign-on is valid for all hosts within the domain of the request host name.
Multiple domain names and UseDomainFromURL austin.ibm.com;raleigh.ibm.com; UseDomainFromURL The sign-on is valid for all hosts within the domain of the request host name.

If you specify the UseDomainFromURL, WAS sets the SSO domain name value to the domain of the host that makes the request.
For example, if an HTTP request comes from server1.raleigh.ibm.com, WAS sets the SSO domain name value to raleigh.ibm.com .
The value, UseDomainFromURL, is case insensitive. You can type usedomainfromurl to use this value.
Optional: Enable the Interoperability mode option if you want to support SSO connections in WAS v5.1.1 or later to interoperate with previous versions of the application server.
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. However, this option applies only when the Web inbound security attribute propagation option is enabled. In this case, both the LtpaToken and LtpaToken2 tokens are added to the response. Otherwise, only the LtpaToken2 token is added to the response. If the Web inbound security attribute propagation option is disabled, then only the LtpaToken token is added to the response.
Optional: Enable the Web inbound security attribute propagation option if you want information added during the login at a specific front-end server to propagate to other front-end servers.
The SSO token does not contain any sensitive attributes, but does understand where the original login server exists in cases where it needs to contact that server to retrieve serialized information.
Important: If the following statements are true, IBM recommends that you disable the Web inbound security attribute propagation option for performance reasons:

You do not have any specific information added to the Subject during a login that cannot be obtained at a different front-end server.
You did not add custom attributes to the PropagationToken token using WSSecurityHelper APIs.

If you find that you are missing custom information in the Subject, re-enable the Web inbound security attribute propagation option to see if the information is propagated successfully to other front-end application servers.
If you disable SSO, but use a trust association interceptor instead, you might still need to enable the Web inbound security attribute propagation option if you want to retrieve the same Subject generated at different front-end servers. WAS V6.1.0.9 contains APAR PK43270, which introduces the following two custom properties that might improve performance when security attribute propagation is enabled:

com.ibm.CSI.propagateFirstCallerOnly
If set to true the first caller in the propagation token that stays on the thread is logged when security attribute propagation is enabled. Without setting this property, all of the caller switches are logged, which can affect performance.
com.ibm.CSI.disablePropagationCallerList
If set to true the ability to add a caller or host list in the propagation token is completely disabled. Beneficial when the caller or host list in the propagation token is not needed in the environment.

Click OK.

Example

Configure SSO between Portal 6.0 and Quickr using the domain "internal.setgetweb.mn.us". This is the domain used in both servers...

Users access the Portal server via...
http://amsterdam.internal.setgetweb.mn.us:10038/wps/portal

Users access the My Places portlet and see a list with their Quickr places
Once users click on one of the Places, they are redirected to the Quickr server without having to re-authenticate.

Users can also access the Portal server using other urls such as:

http://amsterdam:10038/wps/portal/
http://ip_address:10038/wps/portal
http://amsterdam.setgetweb.local:10038/wps/portal/

When step #3 above is executed users are required to authenticate again. This is normal due to difference between domain names.
One way to get around this restriction is to use mod_rewrite to create a redirect rule matches the above URLs and redirects them to..
amsterdam.internal.setgetweb.mn.us

What to do next

For the changes to take effect, save, stop, and restart all the product servers.

Related concepts
Create a single sign-on for HTTP requests using the SPNEGO TAI
Configure single sign-on capability with Tivoli Access Manager or WebSEAL
Web component security
Lightweight Third Party Authentication
Security attribute propagation

Related tasks
Enable security
Configure the Lightweight Third Party Authentication mechanism Authenticate users

Related reference
Single sign-on configuration troubleshooting tips
Security: Resources for learning
Security custom properties


Token type	Purpose	To specify
LtpaToken only	Used for the same SSO behavior existing in WAS V5.1 and previous releases	Disable the Web inbound security attribute propagation option, located in... Security \| Secure administration, applications, and infrastructure \| Web security \| SSO
LtpaToken2 only	Used for Web inbound security attribute propagation and uses the AES, CBC, PKCS5 padding encryption strength (128-bit key size). Not interoperable with releases prior to WAS V5.1.1. The token type supports multiple attributes that are specified in the token, mostly containing information to contact the original login server.	Enable the Web inbound security attribute propagation option in the SSO configuration panel within the administrative console. Disable the Interoperability mode option in the SSO configuration panel within the administrative console. Security \| Secure administration, applications, and infrastructure \| Web security \| Single sign-on (SSO)
LtpaToken and LtpaToken2	These tokens together support both of the previous two options. The token types are interoperable with releases prior to WAS V5.1.1 because LtpaToken is present. The security attribute propagation function is enabled because the LtpaToken2 is present.	Enable the Web inbound security attribute propagation and Interoperability mode options in... Security \| Secure administration, applications, and infrastructure \| Web security \| Single sign-on (SSO)

Domain name value type	Example	Purpose
Blank		The domain is not set. This causes the browser to set the domain to the request host name. The sign-on is valid on that single host only.
Single domain name	austin.ibm.com	If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
UseDomainFromURL	UseDomainFromURL	If the request is to a host within the configured domain, the sign-on is valid for all hosts within that domain. Otherwise, it is valid on the request host name only.
Multiple domain names	austin.ibm.com;raleigh.ibm.com	The sign-on is valid for all hosts within the domain of the request host name.
Multiple domain names and UseDomainFromURL	austin.ibm.com;raleigh.ibm.com; UseDomainFromURL	The sign-on is valid for all hosts within the domain of the request host name.