Implement single sign-on


 

+

Search Tips   |   Advanced Search

 

With SSO support, Web users can authenticate once when accessing Web resources across multiple WASs. Form login mechanisms for Web apps require that SSO is enabled. Use this topic to configure single sign-on for the first time.

SSO is supported only when Lightweight Third Party Authentication (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.

For requests between different cells, to work, share the LTPA keys and the user registry between the cells. Realm names on each system in the SSO domain are case sensitive and must match identically.

The LTPA authentication mechanism requires that you enable SSO if any of the Web apps have form login as the authentication method.

When you enable security attribute propagation, the LtpaToken2 cookie is always added to the response. The LtpaToken2 cookiie is generated for WAS v5.1.1 and beyond. It enables you to add multiple attributes to the token. This token contains...

If the interoperability mode flag is enabled, the LtpaToken cookie is optionally added to the response. The LtpaToken is generated for releases prior to WAS v5.1.1. It is used for inter-operating with previous releases of WAS and contains the authentication identity attribute only.

Token type Purpose How to specify
LtpaToken2 only Default token type. Uses the AES-CBC-PKCS5 padding encryption strength (128-bit key size). This token is stronger than the older LtpaToken used prior to WAS V6.02. This is the recommended option when interoperability with older releases is not necessary. Disable the Interoperability mode option...

Security | Global security | Web security | Single sign-on (SSO)

LtpaToken
LtpaToken2 		Use to interoperate with releases prior to WAS V5.1.1. The older LtpaToken cookie is present along with the new LtpaToken2 cookie. Provided the LTPA keys are correctly shared, you should be able to interoperate with any version of WebSphere using this option. Enable the Interoperability mode option...

Security | Global security | Web security | Single sign-on (SSO)

The following steps are required to configure SSO for the first time.

  1. From admin console

    Security | Global security | Web security | Single sign-on (SSO)

  2. Click the Enabled option if SSO is disabled.

    After you click the Enabled option, make sure that you complete the remaining steps to enable security.

  3. Click Requires SSL if all of the requests are expected to use HTTPS.

  4. Enter the fully qualified domain names in the Domain name field where SSO is effective.

    If we 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, we 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 we specify...

    foobar.com; mpls.setgetweb.com

    ..and a match is found in the foobar.com domain first, WAS does not continue to search for a match in the mpls.setgetweb.com domain.

    If a match is not found in either the foobar.com or mpls.setgetweb.com domains, WAS does not set a domain for the LtpaToken cookie.

    We can configure the Domain name field using...

    Domain name 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 mpls.setgetweb.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 mpls.setgetweb.com;amsterdam.foobar.com The sign-on is valid for all hosts within the domain of the request host name.
    Multiple domain names
    UseDomainFromURL     		mpls.setgetweb.com;amsterdam.foobar.com; UseDomainFromURL The sign-on is valid for all hosts within the domain of the request host name.

    If we specify 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.amsterdam.foobar.com

    ...WAS sets the SSO domain name value to...

    amsterdam.foobar.com

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

  5. 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. If the Web inbound security attribute propagation option is disabled, then only the LtpaToken token is added to the response.

  6. Enable Web inbound security attribute propagation if we 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. It also contains the cache look-up value for finding the serialized information in DynaCache, if both front-end servers are configured in the same DRS replication domain.

    If the following statements are true, disable Web inbound security attribute propagation 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 we find that we 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 appservers.

    The following two custom properties might help to improve performance when security attribute propagation is enabled:

    • com.ibm.CSI.propagateFirstCallerOnly

      If 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 true the ability to add a caller or host list in the propagation token is completely disabled. This function is beneficial when the caller or host list in the propagation token is not needed in the environment.

  7. Click OK.

 

What to do next

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


Create a single sign-on for HTTP requests using SPNEGO Web authentication
Create a single sign-on for HTTP requests using the SPNEGO TAI (deprecated)
Set single sign-on capability with TAM or WebSEAL

 

Related concepts

Web component security
Lightweight Third Party Authentication
Security attribute propagation

 

Related tasks

Enable security
Set the Lightweight Third Party Authentication mechanism
Authenticate users

 

Related

Single sign-on configuration troubleshooting tips for security
Security: Links