+

Search Tips   |   Advanced Search

 

Configure single sign-on capability with SPNEGO TAI

 

WAS 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 WAS. To deploy and use the SPNEGO TAI we need to examine your installation and decide on how best to configure the SPNEGO TAI. 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 > Secure administration, applications, and infrastructure > Authentication mechanisms and expiration.

Enabling Web security SSO is optional when you configure the SPNEGO TAI. For more information, see Implementing single sign-on to minimize Web user authentications.

 

Overview

Answer the following questions to establish how the SPNEGO TAI is deployed.

 

Procedure

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

    See SPNEGO TAI custom configuration attributes 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 user Ids from client to server for SPNEGO 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 two different Kerberos encryption types: RC4-HMAC and DES-CBC-MD5. The IBM Java Generic Security Service (JGSS) library (and SPNEGO library) support both of these encryption types.

    RC4-HMAC encryption is only supported with a Windows 2003 Server key distribution center (KDC). RC4-HMAC encryption is not supported when using a Windows 2000 Server as a Kerberos KDC.

  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 WAS 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 WAS.

  6. How frequently will appservers 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 WAS configuration data. See SPNEGO TAI JVM configuration attributes for more information about these reload properties.

 

Results

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.


Configure WAS environment to use SPNEGO

Configure the Web browser to use SPNEGO

 

Related tasks


Filtering HTTP requests for SPNEGO TAI
Mapping user Ids from client to server for SPNEGO
Implementing single sign-on to minimize Web user authentications

 

Related Reference


SPNEGO TAI custom configuration attributes
SPNEGO TAI JVM configuration attributes