Single sign-on for HTTP requests using SPNEGO web authentication

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

The following sections describe SPNEGO web authentication in more detail:

What is SPNEGO?

SPNEGO is a standard specification that is defined in The Simple and Protected GSS-API Negotiation Mechanism (IETF RFC 2478).

When Liberty server security is enabled, and SPNEGO web authentication is enabled, SPNEGO is initialized when processing a first inbound HTTP request. When the authentication filter is not specified, or the authentication filter is specified and the criteria is met, SPNEGO is responsible for authenticating access to the protected 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:
  • For Windows platformsMicrosoft Windows 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 and Mozilla Firefox are browser examples. Any browser that is being used must be configured to use the SPNEGO web authentication mechanism.

The authentication of HTTP requests is triggered by the user (the client-side), which generates an SPNEGO token. WebSphere Application Server receives this token. Specifically, the SPNEGO web authentication decodes and retrieves the user identity from the SPNEGO token. The identity is then used to make authorization decisions.

SPNEGO web authentication is a server-side solution in the WebSphere Application Server. Client-side applications are responsible for generating the SPNEGO token for use by SPNEGO web authentication. The user 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.

WebSphere Application Server validates the identity against its security registry. If the validation is successful, the client GSS delegation credential is retrieved and placed in the client subject, and a Lightweight Third Party Authentication (LTPA) security token is created. It then returns the LTPA cookie to the user in the HTTP response. Subsequent HTTP requests from this same user to access more protected resources in the WebSphere Application Server use the LTPA security token that is previously created to avoid repeated login challenges.

SPNEGO web authentication in a single Kerberos realm

SPNEGO web authentication is supported in a single Kerberos realm (domain). The challenge-response handshake process is shown in the following figure:

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

  1. To begin, the user logs on to the Microsoft domain controller MYDOMAIN.EXAMPLE.COM from the workstation.
  2. Next, the user attempts to access the Web application. The user requests a protected Web resource using a client browser, which sends an HTTP GET request to the Liberty server.
  3. SPNEGO authentication in the Liberty server answers the client browser with an HTTP 401 challenge header that contains the Authenticate: Negotiate status.
  4. The client browser recognizes the negotiate header because the client browser is configured to support integrated Windows authentication. The client parses the requested URL for the host name. The client uses the host name to form the target Kerberos service principal name (SPN) HTTP/myLibertyMachine.example.com to request a Kerberos service ticket from the Kerberos ticket-granting service (TGS) in the Microsoft Kerberos KDC (TGS_REQ). The TGS then issues a Kerberos service ticket (TGS_REP) to the client. The Kerberos service ticket (SPNEGO token) proves both the user's identity and permissions to the service (Liberty server).
  5. The client browser then responds to the Liberty server Authenticate: Negotiate challenge with the SPNEGO token that is obtained in the previous step in the request HTTP header.
  6. SPNEGO authentication in the Liberty server sees the HTTP header with the SPNEGO token, validates the SPNEGO token, and gets the identity (principal) of the user.
  7. After the Liberty server gets the identity of the user, it validates the user in its user registry and performs the authorization checks.
  8. If access is granted, the Liberty server sends the response with an HTTP 200. The Liberty server also includes an LTPA cookie in the response. This LTPA cookie is used for subsequent requests.
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 previously. Those clients can obtain a ticket-granting ticket (TGT) and a Kerberos service ticket for the target server, create an SPNEGO token, insert it in the HTTP header, and then follow the normal process for creating an HTTP request.

SPNEGO web authentication in trusted Kerberos realms

SPNEGO web authentication is also supported in trusted Kerberos realms. The challenge-response handshake process is shown in the following figure:

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

  1. The user logs in to the Microsoft domain controller TRUSTEDREALM.ACME.COM.
  2. From a client browser, the user makes a request for a protected Web resource that is hosted on a Liberty server in the original Microsoft domain controller, MYDOMAIN.EXAMPLE.COM.
  3. The Liberty server answers the client browser with an HTTP 401 challenge header that contains the Authenticate: Negotiate status.
  4. The client browser is configured to support integrated Windows authentication. The client browser parses the URL by using the host name of the workstation that hosts the Liberty server application. The client browser uses the host name as an attribute to request a Kerberos cross-realm ticket (TGS_REQ) for MYDOMAIN.EXAMPLE.COM from realm TRUSTEDREALM.ACME.COM.
  5. The client browser uses the Kerberos cross-realm ticket from step 4 to request a Kerberos service ticket from realm MYDOMAIN.EXAMPLE.COM. The Kerberos service ticket (SPNEGO token) proves the user's identity and permissions to the service (Liberty server).
  6. The client browser then responds to the Liberty server Authenticate: Negotiate challenge with the SPNEGO token that is obtained in the previous step in the request HTTP header.
  7. The Liberty server receives the request and checks the HTTP header with the SPNEGO token. It then extracts the Kerberos service ticket, validates the ticket, and gets the identity (principal) of the user.
  8. After the Liberty server gets the identity of the user, it validates the user in its user registry and performs the authorization checks.
  9. If access is granted, the Liberty server sends the response with an HTTP 200. The Liberty server also includes an LTPA cookie in the response. This LTPA cookie is used for subsequent requests.
Note: No modification is required to the Liberty server to support more trusted realms. A trust relationship between the necessary Active Directory realms is the only requirement for SPNEGO to work with trusted realms.

In the trusted Kerberos realms environment, be aware that the Kerberos trusted realm setup has to be completed on each of the Kerberos KDCs. See your Kerberos Administrator and User's guide for more information about how to set up Kerberos trusted realms.

Support information for SPNEGO web authentication with a browser client or a non-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

SPNEGO authentication can authenticate with either a SPNEGO token or a Kerberos service ticket (Kerberos token).

For further information on configuring SPNEGO on the Liberty server, see Configuring SPNEGO authentication in Liberty.