Single sign-on capability with SPNEGO TAI - checklist (deprecated)

WebSphere® Application Server provides a trust association interceptor (TAI) that uses the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) to securely negotiate and authenticate HTTP requests for secured resources in WebSphere Application Server. To deploy and use the SPNEGO TAI you need to examine your installation and decide on how best to configure the SPNEGO TAI.

Deprecated feature:

In WebSphere Application Server Version 6.1, a trust association interceptor (TAI) that uses the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) to securely negotiate and authenticate HTTP requests for secured resources was introduced. In WebSphere Application Server 7.0, this function is now deprecated. SPNEGO web authentication has taken its place to provide dynamic reload of the SPNEGO filters and to enable fallback to the application login method.

Lightweight Third Party Authentication (LTPA) is the default authentication mechanism for WebSphere Application Server. However, you may need to configure LTPA prior to configuring the SPNEGO TAI. LTPA is the required authentication mechanism for all trust association interceptors. You can configure LTPA by clicking Security > Global security > Authentication mechanisms and expiration.
Note: Enabling web security single sign-on (SSO) is optional when you configure the SPNEGO TAI. For more information, see Configuring single sign-on.
Answer the following questions to establish how the SPNEGO TAI is deployed.
  1. What is your criteria for intercepting HTTP requests?

    You must decide if the SPNEGO TAI deployment will use the HTTPHeaderFilter class as the default. If you do use this class, then you must specify the exact filter properties for this class. The default behavior of the SPNEGO TAI is to use the com.ibm.ws.spnego.HTTPHeaderFilter class to intercept all requests.

    If you do not use the sample com.ibm.ws.spnego.HTTPHeaderFilter class, then you must define a new class that implements the com.ibm.wsspi.security.spnego.SpnegoTAIFilter interface.

    You can decide to further control what HTTP requests are intercepted using the Service Provider Programming Interface (SPI), Filtering HTTP requests for SPNEGO TAI (deprecated)

    See SPNEGO TAI custom properties configuration (deprecated) for descriptions of
    • com.ibm.ws.security.spnego.SPN<id>.filterClass
    • com.ibm.ws.security.spnego.SPN<id>.filter
  2. Is user Id mapping to be used? If not, why not?

    WebSphere Application Server enables you to define or develop a custom login module to map user IDs. See Mapping Kerberos client principal name to WebSphere user registry ID for SPNEGO TAI (deprecated) for more detail about performing this mapping.

    You must decide, before deploying the TAI, whether or not to use this custom login module to perform the SPNEGO TAI identity mapping

  3. What type of encryption is to be used to process the SPNEGO tokens?
    Microsoft Windows Active Directory supports the RC4-HMAC Kerberos encryption types. The IBM® Java™ Generic Security Service (JGSS) library (and SPNEGO library) support this encryption type.
    Restriction: RC4-HMAC encryption is only supported with a Windows 2003 Server key distribution center (KDC).
    Important: RC4-HMAC is now considered a weak cipher and no longer supported by Windows by default. Use stronger ciphers such as aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96.
  4. How will you handle credential delegation?

    Kerberos supports the delegation of credentials. A server that receives Kerberos credentials from a client can impersonate that client to other servers by using delegated credentials. Since SPNEGO TAI tokens are a wrapping of a Kerberos credential, a server that receives Kerberos credentials within an SPNEGO token can use those Kerberos credentials to impersonate the original user. That server can interact using SPNEGO over HTTP as a SPNEGO client to other SPNEGO servers by composing an appropriate HTTP Authorization header.

  5. Will the SPNEGO TAI be deployed in a single or multiple domain name service (DNS) domain environment?

    Web browsers running on Windows are sensitive to DNS domains. They only send a SPNEGO token when the target host name identifies a host name defined in the DNS domain of the client machine. You can use HTTP redirection to support this configuration with the creation of a pseudo Kerberos service principal name (SPN) in each DNS domain. All SPNs that WebSphere Application Server supports must have their secret keys available in Kerberos keytab files. To enable single sign-on across multiple DNS domains, a separate Kerberos keytab file is generated for each SPN per domain. These individual Kerberos keytab files must be merged before they can be used by WebSphere Application Server.

  6. How frequently will application servers reload the SPNEGO TAI properties?

    The SPNEGO TAI has an optional property reload feature that allows the reloading of the TAI properties without restarting the Java virtual machine (JVM). This reload feature is controlled by the system properties com.ibm.ws.security.spnego.propertyReloadFile and com.ibm.ws.security.spnego.propertyReloadTimeout. These properties taken together enable the SPNEGO TAI internal properties to be reloaded from a file on the file system after a certain time period. If the com.ibm.ws.security.spnego.propertyReloadTimeout attribute is set to a valid integer value, and the com.ibm.ws.security.spnego.propertyReloadFile attribute points to a file on the file system, then each JVM reloads the SPNEGO TAI properties from the file after the timeout period expires. Also, the SPNEGO TAI properties are reloaded only if the date on the file has changed. If these reload properties are not set, then the SPNEGO TAI properties are only loaded once, at JVM initialization, from the SPNEGO TAI custom properties that are defined in WebSphere Application Server configuration data. See SPNEGO TAI JVM configuration custom properties (deprecated) for more information about these reload properties.

The Windows Active Directory (Web) administrator, the WebSphere Application Server administrator, and the application team review and answer these questions to determine the best deployment and configuration settings for the SPNEGO TAI.