Single sign-on capability with SPNEGO TAI - checklist
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.
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 | Secure administration, applications, and infrastructure | Authentication mechanisms and expirationEnabling Web security single sign-on (SSO) is optional when you configure the SPNEGO TAI. Answer the following questions to establish how the SPNEGO TAI is deployed.
- 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 class...
com.ibm.ws.spnego.HTTPHeaderFilter...to intercept all requests.
If you do not use the sample class...
com.ibm.ws.spnego.HTTPHeaderFilter...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 properties configuration for descriptions of
- com.ibm.ws.security.spnego.SPN<id>.filterClass
- com.ibm.ws.security.spnego.SPN<id>.filter
- 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 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
- 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. Restriction: 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.
- 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.
- 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.
- 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 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.
Related tasks
Configuring the client browser to use SPNEGO
Filtering HTTP requests for SPNEGO TAI
Mapping Kerberos client principal name to WebSphere user registry ID for SPNEGO Creating a single sign-on for HTTP requests using the SPNEGO TAI
Related reference
SPNEGO TAI custom properties configuration
SPNEGO TAI JVM configuration custom properties