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.
New 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 Version 7.0, this
function is now deprecated. 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.
newfeat
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® 2000 or Windows 2003
Servers with Active Directory domain and associated Kerberos Key Distribution
Center (KDC).
- 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 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 2000
or 2003 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:
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 following
steps to set up Kerberos as the authentication mechanism for
WebSphere Application Server.
Note: Kerberos
authentication mechanism on the server side must be done by the system
administrator. The Kerberos keytab file must be protected.
- Ensure that the KDC is configured.
See your Kerberos Administrator
and User's guide for more information.
- The IBM® Java™ Generic
Security Service (JGSS) and KRB5 require a Kerberos configuration
file (krb5.conf or krb5.ini) on each node or Java virtual machine (JVM). In this release
of WebSphere Application Server, this configuration
file should be placed in the config/cells/<cell_name> directory
so that all application servers can access this file. If you do not
have a Kerberos configuration file, use a wsadmin command to
create one.
Read about Creating a Kerberos configuration file for more information.
Create a Kerberos
keytab file that contains the Kerberos service principal (SPN) for
each SPNEGO Web authentication filter host name. The format of the
SPN is HTTP/<fully qualified hostname>. SPNEGO uses
this SPN to validate and establish the security context with the SPNEGO
requester.
To use a remote HTTP server,
you must create the SPN for the remote proxy server and add the proxy
SPN and key to the keytab file.
The Kerberos keytab file (krb5.keytab)
contains all of the SPNs for the node and must be protected. This
file can be placed in the config/cells/<cell_name>
directory.
Read about Creating a Kerberos service principal and keytab file for more information.
Note: SPNEGO Web authentication
and Kerberos authentication both use the same Kerberos configuration
and keytab files.
- Set up SPNEGO Web authentication for WebSphere Application
Server by using the administrative console.
Read about Enabling and configuring SPNEGO Web authentication using the administrative console for more information.
For
information about how to set up SPNEGO Web authentication for WebSphere Application Server by using wsadmin commands,
read about SPNEGO Web authentication configuration commands.
Note: The client, WebSphere Application Server and KDC machines
must keep the clock synchronized. The best practice is to use a time
server to keep all of the systems synchronized.