Single sign-on capability with SPNEGO TAI - checklist (deprecated)
WAS provides a TAI that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources in WAS. To deploy and use the SPNEGO TAI we need to examine the installation and decide on how best to configure the SPNEGO TAI.
In WAS Version 6.1, a TAI that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources was introduced. In WAS 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. depfeat 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. Configure LTPA by clicking Security > Global security > Authentication mechanisms and expiration.
Enabling Web security SSO is optional when you configure the SPNEGO TAI.
See Implementing single sign-on to minimize Web user authentications.
Answer the following questions to establish how the SPNEGO TAI is deployed.
- What is the criteria for intercepting HTTP requests?
You must decide if the SPNEGO TAI deployment will use the HTTPHeaderFilter class as the default. If we 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 we 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.
We 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
- Is user Id mapping to be used? If not, why not?
WAS 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
- 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 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. 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.
- 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 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 defined in WAS configuration data. See SPNEGO TAI JVM configuration custom properties (deprecated) for more information about these reload properties.
The Windows Active Directory (Web) administrator, the WAS administrator, and the application team review and answer these questions to determine the best deployment and settings for the SPNEGO TAI.
Related tasks
Set the client browser to use SPNEGO TAI (deprecated)
Filtering HTTP requests for SPNEGO TAI (deprecated)
Mapping Kerberos client principal name to WebSphere user registry ID for SPNEGO TAI (deprecated)
Create a single sign-on for HTTP requests using the SPNEGO TAI (deprecated)
Related
SPNEGO TAI custom properties configuration (deprecated)
SPNEGO TAI JVM configuration custom properties (deprecated)