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.
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.
Read about Creating a single sign-on for HTTP requests using SPNEGO Web authentication for more information.
depfeat
SPNEGO is a standard specification defined in The Simple and Protected GSS-API Negotiation Mechanism
(IETF RFC 2478).
When
WebSphere Application Server 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 WebSphere Application Server. 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
WebSphere Application Server security runtime services, some external components are required
to completely enable operation of the SPNEGO TAI. The external components
include:
- 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 WebSphere Application Server Version 8.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 Version 5.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 Configuring 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.
WebSphere Application Server receives this
token and validates trust between the requester and
WebSphere Application Server. 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
WebSphere Application Server. Client-side applications
are responsible for generating the SPNEGO token for use by the SPNEGO
TAI. The requester's identity in
WebSphere Application Server 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 Lightweight Directory Access Protocol (LDAP) server that is
used in
WebSphere Application Server. A
custom login module is available as a plug-in to support custom mapping
of the identity from the Active Directory to the
WebSphere Application Server 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.
WebSphere Application Server validates the
identity against its security registry and, if the validation is successful,
produces a Lightweight Third Party Authentication (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
WebSphere Application Server 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, WebSphere Application Server - SPNEGO TAI

The SPNEGO TAI can be enabled for all or for selected
WebSphere Application Servers in a
WebSphere Application Server cell configuration.
Also, the behavior of each SPNEGO TAI instance is controlled by custom
configuration properties that are 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:
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 Configuring the Lightweight Third Party Authentication 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 (jre/lib/ibmjgssprovider.jarapp_server_root/java/endorsed/ibmjgssprovider.jar) and used to obtain the Kerberos security context and credentials
that are 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. For more information, 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
you 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.
Using 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 /$WAS_HOME/java/jre/lib/ext/ibmspnego.jarapp_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
WebSphere Application Server use the SPNEGO
TAI include:
- 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.
Using the SPNEGO TAI in your
WebSphere Application Server 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 WebSphere Application Server to
respond to HTTP requests of the client.
- WebSphere Application Server administrator
- The WebSphere Application Server administrator
is responsible for configuring WebSphere Application Server and the SPNEGO
TAI for optimum installation performance.
See
Creating a single sign-on for HTTP requests using the SPNEGO TAI (deprecated) for an explanation of the tasks required to use the SPNEGO TAI and
how the responsible party performs these tasks.