SPNEGO single sign-on
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.
- 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?
- The benefits of SPNEGO web authentication
- SPNEGO web authentication in a single Kerberos realm
- SPNEGO web authentication in a trusted Kerberos realm
- Support information for SPNEGO web authentication with a Java client using the HTTP protocol
- Support information for SPNEGO web authentication with a browser client
- Setting up SPNEGO as the web authentication mechanism for WebSphere Application Server
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.
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 8.5 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. Mozilla Firefox is a browser example. 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.
In the following figure, the web administrator has access to the SPNEGO security components and associated configuration data: Web Authentication module, SPNEGO Trust Association Interceptor, JGSS and SPNEGO security providers, Kerberos configuration and Kerberos keytab files, SPNEGO TAI configuration properties and JVM system properties.
![A diagram that shows the relationship between SPNEGO and security configuration elements](images/SPNEGO_3.gif)
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:
![SPNEGO web authentication is supported in a single Kerberos realm. The challenge-response handshake process is shown.](images/SPNEGO_1.gif)
In the previous figure, 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. A
KRBAuthnToken
with a client Kerberos credential is created. - 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.
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:
![SPNEGO web authentication is also supported in a trusted Kerberos realm. The challenge-response handshake process is shown.](images/SPNEGO_2.gif)
In the previous figure, 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. A
KRBAuthnToken
with a client Kerberos credential is created. - 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:
- The Kerberos trusted realm setup must be done 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.
- The Kerberos client principal name from the SPNEGO token might not exist in the WebSphere user registry; the Kerberos principal mapping to the WebSphere user registry might require it.
Read about Mapping of a client Kerberos principal name to the WebSphere user registry ID for more information.
Support information for SPNEGO web authentication with a Java™ client using the HTTP protocol
- Domain trust within the same forest
- External domain trust directly between domains within different forests.
- Kerberos realm trust
- Cross-forest trust
- Forest external trust
Support information for SPNEGO web authentication with a browser client
- Cross-forest trusts
- Domain trust within the same forest
- Kerberos realm trust
- Forest external trusts
- Domain external trusts