Chapter 11. SPNEGO and Windows single sign-on 397
SPNEGO supports both Active Directory credentials (based on Kerberos) and
the older style (and less secure) NTLM credentials. The WebSphere SPNEGO
TAI supports only the Active Directory credentials.
The WebSphere SPNEGO TAI handles the SPNEGO handshake requests,
retrieves the identity from the SPNEGO token, and transfers this identity to
WebSphere run time as a principal.
Essentially, when WebSphere Application Server (WAS) receives an inbound
request that requires authentication, the TAI is invoked. If the requests meets
certain customizable filter criteria, the TAI responds with a SPNEGO challenge to
the Web browser. If a proper SPNEGO token is returned, the TAI uses the WAS
and JDK built-in JGSS services and the SPNEGO provider to parse the token
and determine the user’s identity. This information is then provided to the WAS
run time. WAS uses this information to create an LTPA cookie, which is sent to
the browser. The user is now authenticated. Future requests within the same
SSO domain do not invoke the TAI since the LTPA cookie now represents the
The SPNEGO TAI can work with Web services clients for HTTP transport-level
security with SPNEGO tokens. The SPNEGO TAI is for Web client authentication
and is not relevant for EJB clients.
11.2 Designing single sign-on with Microsoft Windows
In this section we present two solutions for single sign-on between a Microsoft
Windows Active Directory domain and WebSphere Application Server for z/OS.
11.2.1 Single sign-on with Microsoft Windows KDC only
The benefits of having WebSphere Application Server for z/OS use the SPNEGO
TAI single sign-on solution include:
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 .NET clients is established.
Interoperability with Web services and .NET applications that use SPNEGO
authentication at the transport level is achieved.
Previously, this could only be achieved through third-party software such as
Tivoli Access Manager. This can now be achieved by having a SPNEGO
protocol enabled client such as a .NET application or SPNEGO enabled
398 Security in WebSphere Application Server Version 6.1 and J2EE 1.4 on z/OS
browsers such as Microsoft Internet Explorer 5.5 and later or Mozilla Firefox 1.0.
These clients establish trust and pass credentials to WebSphere Application
Server for z/OS using Kerberos tickets wrapped in SPNEGO tokens issued from
a Microsoft Windows 2000 or 2003 Active Directory domain controller.
In a simple solution, there is one Microsoft Windows Active Directory domain with
one Kerberos KDC. The WebSphere Application Server for z/OS service is
defined as kerberized in the Windows Kerberos KDC and the corresponding
principal keytab file is transferred to the WebSphere for z/OS configuration.
The Windows client workstation authenticates to the Windows domain and
interacts with the Windows Kerberos KDC. When this Windows client workstation
accesses the z/OS Web application, it uses a Kerberos service ticket wrapped in
a SPNEGO token to single sign-on with WebSphere Application Server for z/OS.
See Figure 11-2.
Figure 11-2 Single sign-on with Microsoft Windows KDC only