You can securely negotiate and authenticate HTTP requests
for secured resources in WebSphere® Application Server by using the Simple
and Protected GSS-API Negotiation Mechanism (SPNEGO) as the web authentication
service for WebSphere Application Server.
Note: 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. This function was deprecated in
WebSphere Application Server Version 7.0. SPNEGO
web authentication has taken its place to provide the following enhancements:
- You can configure and enable SPNEGO web authentication and filters
on WebSphere Application Server by using
the administrative console.
- Dynamic reload of SPNEGO is provided without the need to stop
and restart WebSphere Application Server.
- Fallback to an application login method is provided if the SPNEGO
web authentication fails.
- SPNEGO can be customized at the WebSphere security domain level. Read about Multiple security domains for more
information.
You can enable either SPNEGO TAI or SPNEGO Web Authentication but
not both.
The following sections describe SPNEGO web authentication in more
detail:
What is SPNEGO?
SPNEGO is
a standard specification defined in The Simple and Protected GSS-API Negotiation Mechanism
(IETF RFC 2478).
When WebSphere Application Server global and application
security are enabled, and SPNEGO web authentication is enabled, SPNEGO
is initialized when processing a first inbound HTTP request. The web
authenticator component then interacts with SPNEGO, which is defined
and enabled in the security configuration repository. When the filter
criteria is met, SPNEGO is responsible for authenticating access to
the secured resource that is identified in the HTTP request.
In addition to
WebSphere Application Server security runtime services, some external components are required
to enable the operation of SPNEGO. These 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 7.0 on Windows.
- A client application, for example, Microsoft .NET, or web service and J2EE
client that supports the SPNEGO web 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 must be configured to use the
SPNEGO web authentication mechanism. For more information on performing
this configuration, see Configuring the client browser to use SPNEGO.
The authentication of HTTP requests is triggered by the
requestor (the client-side), which generates a SPNEGO token. WebSphere Application Server receives this
token. Specifically, the SPNEGO web authentication 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.
SPNEGO web authentication is a server-side solution
in WebSphere Application Server. Client-side
applications are responsible for generating the SPNEGO token for use
by SPNEGO web authentication. The requester's identity in the WebSphere Application Server security registry
must be identical to the identity that the SPNEGO web authentication
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.
Read about Mapping of a client Kerberos principal name to the WebSphere user registry ID for more information about
using this custom login module.
WebSphere Application Server validates the
identity against its security registry. If the validation is successful,
the client Kerberos ticket and GSS delegation credential are retrieved
and placed in the client subject, which then produces a Lightweight
Third Party Authentication (LTPA) security token. It then 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 web administrator has access to the following
SPNEGO security components and associated configuration data, as shown
in the following figure:
Figure 1. SPNEGO web authentication
and security configuration elements
The benefits of SPNEGO web authentication
The benefits of having WebSphere Application Server use SPNEGO as
the web authentication service for WebSphere Application Server include the following:
- An integrated single sign-on
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, or web service applications
that use SPNEGO authentication at the transport level is achieved.
- With Kerberos authentication support, SPNEGO web authentication
can provide an end-to-end SPNEGO to Kerberos solution and preserve
the Kerberos credential from the client.
SPNEGO web authentication in a single
Kerberos realm
SPNEGO web authentication is supported in
a single Kerberos realm. The challenge-response handshake process
is shown in the following figure:
Figure 2. SPNEGO web authentication in a single Kerberos realm
In the figure
above, the following events occur:
- The client sends an HTTP/Post/Get/Web-Service request to WebSphere Application Server.
- WebSphere Application Server returns HTTP 401 Authenticate/Negotiate.
- The client obtains a Ticket Granting Ticket (TGT).
- The client requests a Service Ticket (TGS_REQ).
- The client obtains a Service Ticket (TGS_REP).
- The client sends HTTP/Post/Get/Web-Service and an authorization
SPNEGO token to WebSphere Application Server.
- WebSphere Application Server validates
the SPNEGO token. If the validation is successful, it retrieves the
user ID and the GSS delegation credential from the SPNEGO token. Create
a KRBAuthnToken with a client Kerberos credential.
- WebSphere Application Server validates
the user ID with the WebSphere user registry and creates an LTPA token.
- WebSphere Application Server returns HTTP 200, content and the LTPA token to the client.
Note: Other clients (for example, web services, .NET and
J2EE) that support SPNEGO do not have to follow the challenge-response
handshake process as shown above. Those clients can obtain a ticket-granting
ticket (TGT) and a Kerberos service ticket for the target server,
create a SPNEGO token, insert it in the HTTP header, and then follow
the normal process for creating an HTTP request.
SPNEGO web authentication in a
trusted Kerberos realm
SPNEGO web authentication is also
supported in a trusted Kerberos realm. The challenge-response handshake
process is shown in the following figure:
Figure 3. SPNEGO web authentication in a trusted Kerberos realm
In the figure
above, the following events occur:
- The client sends an HTTP/Post/Get/Web-Service request to WebSphere Application Server.
- WebSphere Application Server returns HTTP 401 Authenticate/Negotiate
- The client obtains a Ticket Granting Ticket (TGT).
- The client requests a cross realm ticket (TGS_REQ) for REALM2 from the REALM1 KDC.
- The client uses the cross-realm ticket from step 4 to request
a Service Ticket from the REALM2 KDC.
- The client sends HTTP/Post/Get/Web-Service and an authorization
SPNEGO token to WebSphere Application Server.
- WebSphere Application Server validates
the SPNEGO token. If the validation is successful, it retrieves the
user ID and the GSS delegation credential from the SPNEGO token. Create
a KRBAuthnToken with a client Kerberos credential.
- WebSphere Application Server validates
the user ID with the WebSphere user registry and creates an LTPA token.
- WebSphere Application Server returns HTTP 200, content and the LTPA token to the client.
In the trusted Kerberos realms environment, be aware of
the following:
Support information for SPNEGO
web authentication with a Java client using the HTTP protocol
The following scenarios
are supported:
- Domain trust within the same forest
- External domain trust directly between domains within different
forests.
- Kerberos realm trust
The following scenarios are not supported:
- Cross-forest trust
- Forest external trust
Support information for
SPNEGO web authentication with a browser client
The following
scenarios are supported:
- Cross-forest trusts
- Domain trust within the same forest
- Kerberos realm trust
The following scenarios are not supported:
- Forest external trusts
- Domain external trusts
Setting up SPNEGO as the web authentication
mechanism for WebSphere Application Server
Before you set up SPNEGO web authentication
in the administrative console or by using
wsadmin commands,
you must perform the steps as listed in
Creating a single sign-on for HTTP requests using SPNEGO Web authentication to set up SPNEGO web authentication for
WebSphere Application Server.
Note: SPNEGO
web authentication on the server side must be done by the system administrator.
The Kerberos keytab file must be protected.