Single sign-on for HTTP requests using SPNEGO TAI (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 WAS.
Deprecated feature:
In WAS v6.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 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.
Read about Create a single sign-on for HTTP requests using SPNEGO Web authentication for more information.
depfeatSPNEGO is a standard specification defined in The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478).
When WAS administrative security is enabled, the SPNEGO TAI is initialized. While processing inbound HTTP requests, the web authenticator component interacts with the SPNEGO TAI, which is defined and enabled in the security configuration repository. One interceptor is selected and is responsible for authenticating access to the secured resource that is identified in the HTTP request.
Important: The use of TAIs is an optional feature. If no TAI is selected, the authentication process continues normally.
HTTP users log in and authenticate only once at their desktop and are subsequently authenticated (internally) with WAS. The SPNEGO TAI is invisible to the end-user of WebSphere applications. The SPNEGO TAI is only visible to the web administrator who is responsible for ensuring a proper configuration, capacity, and maintenance of the web environment.
In addition to WAS security runtime services, some external components are required to completely enable operation of the SPNEGO TAI. The external components include:
- (Windows) Microsoft Windows Servers with Active Directory domain and associated Kerberos Key Distribution Center (KDC). For information on the supported Microsoft Windows Servers, see the System Requirements for WAS v9.0 on Windows.
- A client application, for example, a browser or Microsoft .NET client, that supports the SPNEGO authentication mechanism, as defined in IETF RFC 2478. Microsoft Internet Explorer v5.5 or later and Mozilla Firefox Version 1.0 are browser examples. Any browser needs to be configured to use the SPNEGO mechanism. For more information on performing this configuration, see Configure the client browser to use SPNEGO TAI (deprecated).
The authentication of HTTP requests is triggered by the requestor (the client-side), which generates a SPNEGO token. WAS receives this token and validates trust between the requester and WAS. Specifically, the SPNEGO TAI decodes and retrieves the requester's identity from the SPNEGO token. The identity is used to establish a secure context between the requester and the application server.
Remember: The SPNEGO TAI is a server-side solution in WAS. Client-side applications are responsible for generating the SPNEGO token for use by the SPNEGO TAI. The requester's identity in WAS security registry must be identical to that identity the SPNEGO TAI retrieves. An identical match does occur when Microsoft Windows Active Directory server is the LDAP server used in WAS. A custom login module is available as a plug-in to support custom mapping of the identity from the Active Directory to the WAS security registry. See Mapping Kerberos client principal name to WebSphere user registry ID for SPNEGO TAI (deprecated) for details on using this custom login module. WAS validates the identity against its security registry and, if the validation is successful, produces a LTPA security token and places and returns a cookie to the requester in the HTTP response. Subsequent HTTP requests from this same requester to access additional secured resources in WAS use the LTPA security token previously created, to avoid repeated login challenges.
The challenge-response handshake process is illustrated in the following graphic:
Figure 1. HTTP request processing, WAS - SPNEGO TAI
The SPNEGO TAI can be enabled for all or for selected WAS in a WAS cell configuration. Also, the behavior of each SPNEGO TAI instance is controlled by custom configuration properties used to identify, for example, the criteria used to filter HTTP requests, such as the host name and security realm name used to construct the Kerberos Service Principal Name (SPN). For more information regarding establishing and setting the SPNEGO TAI custom configuration properties, see the following topics:
- Set up the Kerberos configuration properties. See The Kerberos configuration file.
- Setting or adjusting the SPNEGO TAI custom properties. See SPNEGO TAI custom properties configuration (deprecated).
- Adjusting the SPNEGO TAI filter settings. See Configure JVM custom properties, filtering HTTP requests, and enabling SPNEGO TAI in WAS (deprecated)
- Use the custom login module to map the identity from the Active Directory to the WAS registry. See Mapping user Ids from client to server for SPNEGO.
- Setting the major and additional Java virtual machine (JVM) custom properties. See SPNEGO TAI JVM configuration custom properties (deprecated)
The web administrator has access to the following SPNEGO TAI security components and associated configuration data, as illustrated in the following graphic.
Figure 2. SPNEGO TAI security and configuration elements
- The web authentication module and the Lightweight Third Party Authentication (LTPA) mechanism provide the plug-in runtime framework for trust association interceptors. See Configure the LTPA mechanism for more detail is configuring the LTPA mechanism for use with the SPNEGO TAI.
- The Java Generic Security Service (JGSS) provider is included in the Java SDK ((Dist) (ZOS) jre/lib/ibmjgssprovider.jar(iSeries) app_server_root/java/endorsed/ibmjgssprovider.jar) and used to obtain the Kerberos security context and credentials used for authentication. IBM JGSS 1.0 is a Java Generic Security Service Application Programming Interface (GSSAPI) framework with Kerberos V5 as the underlying default security mechanism. GSSAPI is a standardized abstract interface under which can be plugged different security mechanisms based on private-key, public-key and other security technologies. GSSAPI shields secure applications from the complexities and peculiarities of the different underlying security mechanisms. GSSAPI provides identity and message origin authentication, message integrity, and message confidentiality. See JGSS.
- The Kerberos configuration properties (krb5.conf or krb5.ini )
and Kerberos encryption keys (stored in a Kerberos keytab file) are
used to establish secure mutual authentication.
The Kerberos key table manager (Ktab), which is part of JGSS, allows us to manage the principal names and service keys stored in a local Kerberos keytab file. Principal name and key pairs listed in the Kerberos keytab file allow services running on a host to authenticate themselves to the Kerberos Key Distribution Center (KDC). Before a server can use Kerberos, a Kerberos keytab file must be initialized on the host that runs the server.
Use the ktab command to manage the Kerberos keytab file highlights the Kerberos configuration requirements for the SPNEGO TAI as well as the use of Ktab.
- The SPNEGO provider supplies the implementation of the SPNEGO authentication mechanism, located at (Dist) (ZOS) /$WAS_HOME/java/jre/lib/ext/ibmspnego.jar(iSeries) app_server_root/java/ext/ibmspnego.jar.
- The custom configuration properties control the runtime behavior of the SPNEGO TAI. Configuration operations are performed with the administrative console or scripting facilities. Refer to SPNEGO TAI custom properties configuration (deprecated) for more information about these custom configuration properties.
- Java virtual machine (JVM) custom properties control diagnostic trace information for problem determination of the JGSS security provider and use of the property reload feature. SPNEGO TAI JVM configuration custom properties (deprecated) describes these JVM custom properties
The benefits of having WAS use the SPNEGO TAI include:
- (Windows) An integrated single signon environment with Microsoft Windows Servers using Active Directory domain is established.
- The cost of administering a large number of ids and passwords is reduced.
- A secure and mutually authenticated transmission of security credentials from the web browser or Microsoft .NET clients is established.
- Interoperability with web services and Microsoft .NET applications that use SPNEGO authentication at the transport level is achieved.
Use the SPNEGO TAI in our WAS environment requires planning then implementation. See Single sign-on capability with SPNEGO TAI - checklist (deprecated) in planning for SPNEGO TAI. Implementing the use of the SPNEGO TAI is divided into the following areas of responsibility:
- End browser user
- The end user must configure the web browser or Microsoft .NET application to issue HTTP requests that are processed by the SPNEGO TAI.
- Web administrator
- The web administrator is responsible for configuring the SPNEGO TAI of WAS to respond to HTTP requests of the client.
- WAS administrator
- The WAS administrator is responsible for configuring WAS and the SPNEGO TAI for optimum installation performance.
Related: