Single sign-on for HTTP requests using SPNEGO Web authentication


 

+

Search Tips   |   Advanced Search

 

We can authenticate HTTP requests for secured resources in WAS using SPNEGO.

New feature: SPNEGO trust association interceptors were introduced in WAS v6.1. In WAS 7.0, this function is now deprecated. 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.

 

What is SPNEGO?

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

Some external components are required to enable the operation of SPNEGO, including...

The authentication of HTTP requests is triggered by the requestor (the client-side), which generates a SPNEGO token. WAS 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 appserver.

SPNEGO Web authentication is a server-side solution in WAS. 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 MS Windows AD 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 AD to the WAS security registry.

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

 

The benefits of SPNEGO Web authentication

The benefits of having WAS use SPNEGO as the Web authentication service for WAS 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...

In the figure above, the following events occur:

  1. The client sends an HTTP/Post/Get/Web-Service request to WAS.

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

  7. WAS 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. WAS validates the user ID with the WebSphere user registry and creates an LTPA token.

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

In the figure above, the following events occur:

  1. The client sends an HTTP/Post/Get/Web-Service request to WAS.
  2. WAS 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 WAS.
  7. WAS 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. WAS validates the user ID with the WebSphere user registry and creates an LTPA token.
  9. WAS returns HTTP 200, content and the LTPA token to the client.

In the trusted Kerberos realms environment, be aware of the following:

 

Set up SPNEGO as the Web authentication mechanism for

Before you set up SPNEGO Web authentication in the admin console or by using wsadmin commands, perform the following steps to set up Kerberos as the authentication mechanism for WAS.

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

  1. Verify the KDC is configured.

  2. The IBM Java Generic Security Service (JGSS) and KRB5 require a Kerberos configuration file (krb5.conf or krb5.ini) on each node or JVM. In this release of WAS, this configuration file should be placed in the config/cells/<cell_name> directory so that all appservers can access this file. If we do not have a Kerberos configuration file, use a wsadmin command to create one.

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

    SPNEGO Web authentication and Kerberos authentication both use the same Kerberos configuration and keytab files.

  3. Set up SPNEGO Web authentication for WAS by using the admin console.

    For information about how to set up SPNEGO Web authentication for WAS by using wsadmin commands, read about SPNEGO Web authentication configuration commands.

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.


 

Related tasks


Enable and configuring SPNEGO Web authentication
Set the client browser to use SPNEGO
Create a Kerberos service principal and keytab file
Create a single sign-on for HTTP requests using SPNEGO Web authentication

 

Related


SPNEGO Web authentication configuration commands
SPNEGO Web authentication filter commands
SPNEGO troubleshooting tips