+

Search Tips   |   Advanced Search

Single sign-on for HTTP requests using SPNEGO web authentication

We can securely negotiate and authenticate HTTP requests for secured resources in WebSphere Application Server using the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) as the web authentication service for WebSphere Application Server.

In WAS v6.1, a trust association interceptor (TAI) that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources was introduced. This function was deprecated in WAS v7. SPNEGO web authentication has taken its place to provide the following enhancements:

We 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 WAS security runtime services, some external components are required to enable the operation of SPNEGO. These external components include:

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 WAS 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 LDAP server 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 WAS security registry.

Read about (dist)(iseries) 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 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:


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 previous figure, the following events occur:

  1. The client sends an HTTP/Post/Get/Web-Service request to WebSphere Application Server.

  2. WebSphere Application Server returns HTTP 401 Authenticate/Negotiate.

  3. The client obtains a Ticket Granting Ticket (TGT).

  4. The client requests a Service Ticket (TGS_REQ).

  5. The client obtains a Service Ticket (TGS_REP).

  6. The client sends HTTP/Post/Get/Web-Service and an authorization SPNEGO token to WebSphere Application Server.

  7. 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.

  8. WebSphere Application Server validates the user ID with the WebSphere user registry and creates an LTPA token.

  9. WebSphere Application Server returns HTTP 200, content and the LTPA token to the client.

Other clients (for example, web services, .NET and J2EE) that support SPNEGO do not have to follow the challenge-response handshake process as shown previously. 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 previous figure, the following events occur:

  1. The client sends an HTTP/Post/Get/Web-Service request to WebSphere Application Server.

  2. WebSphere Application Server returns HTTP 401 Authenticate/Negotiate

  3. The client obtains a Ticket Granting Ticket (TGT).

  4. The client requests a cross realm ticket (TGS_REQ) for REALM2 from the REALM1 KDC.

  5. The client uses the cross-realm ticket from step 4 to request a Service Ticket from the REALM2 KDC.

  6. The client sends HTTP/Post/Get/Web-Service and an authorization SPNEGO token to WebSphere Application Server.

  7. 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.

  8. WebSphere Application Server validates the user ID with the WebSphere user registry and creates an LTPA token.

  9. 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:

The following scenarios are not supported:


Support information for SPNEGO web authentication with a browser client

The following scenarios are supported:

The following scenarios are not supported:


Set up SPNEGO as the web authentication mechanism for WebSphere Application Server

Before you set up SPNEGO web authentication in the console or by using wsadmin commands, perform the steps as listed in Create a single sign-on for HTTP requests using SPNEGO Web authentication to set up SPNEGO web authentication for WebSphere Application Server.

SPNEGO web authentication on the server side must be done by the system administrator. The Kerberos keytab file must be protected.


Related tasks

  • Create a single sign-on for HTTP requests using SPNEGO Web authentication
  • Enable and configure SPNEGO web authentication using the administrative console
  • Configure the client browser to use SPNEGO
  • Create SPNEGO tokens for J2EE, .NET, Java, web service clients for HTTP requests
  • Create a Kerberos service principal name and keytab file

  • SPNEGO web authentication configuration commands
  • SPNEGO web authentication filter commands
  • SPNEGO troubleshooting tips