Single sign-on for HTTP requests using SPNEGO
WAS provides a trust association interceptor that uses SPNEGO to securely negotiate and authenticate HTTP requests for secured resources in WAS.
When WAS administrative security is enabled, the SPNEGO TAI is initialized.
While processing inbound HTTP requests, the Web authenticator component interacts with the SPNEGO TAI. One interceptor is selected and is responsible for authenticating access to the secured resource that is identified in the HTTP request.
The use of TAIs is an optional feature. If no TAI is selected, the authentication process continues normally.
HTTP users log in and authenticate only once at their desktop and are subsequently authenticated. The SPNEGO TAI is invisible to the end-user and is only visible to administrator.
External components required to enable SPNEGO TAI...
- Microsoft Windows 2000 or Windows 2003 Servers with Active Directory domain and associated Kerberos Key Distribution Center (KDC).
- A client application, for example, a browser or Microsoft .NET client, that supports the SPNEGO authentication mechanism.
Microsoft Internet Explorer V5.5 or later and Mozilla Firefox V1.0 are browser examples. Any browser needs to be configured to use the SPNEGO mechanism.
The requestor (client), generates a SPNEGO token. The SPNEGO TAI retrieves the requester's identity from the SPNEGO token and establishes a secure context between the requester and the application server.
The SPNEGO TAI is a server-side solution in WAS. Client-side applications are responsible for generating the SPNEGO token for use by the SPNEGO TAI.
The requester's identity in the WAS security registry must be identical to the identity the SPNEGO TAI retrieves. An identical match occurs when Microsoft Windows Active Directory server is the LDAP server that is 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 and, if the validation is successful, produces a LTPA security token and 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 challenge-response handshake process...
The SPNEGO TAI can be enabled for all or for selected servers in a WAS cell configuration.
The behavior of each SPNEGO TAI instance is controlled by custom configuration properties that are used to identify, for example...
- Criteria used to filter HTTP requests, such as the host name
- Security realm name used to construct the Kerberos Service Principal Name (SPN)
SPNEGO TAI security components...
The Web authentication module and the LTPA mechanism provide the plug-in runtime framework for trust association interceptors.
The Java Generic Security Service (JGSS) provider is included in the Java SDK...
jre/lib/ibmjgssprovider.jar
...and is used to obtain the Kerberos security context and credentials that are used for authentication.
IBM JGSS 1.0 is a Java Generic Security Service API (GSSAPI) framework with Kerberos V5 as the underlying default security mechanism. GSSAPI is a standardized abstract interface under which can be plugged different security mechanisms based on private-key, public-key and other security technologies. GSSAPI shields secure applications from the complexities and peculiarities of the different underlying security mechanisms. GSSAPI provides identity and message origin authentication, message integrity, and message confidentiality.
The Kerberos configuration properties (krb5.conf or krb5.ini ) and Kerberos encryption keys (stored in a Kerberos keytab file) are used to establish secure mutual authentication.
The Kerberos key table manager (Ktab), part of JGSS, allows you to manage principal names and service keys stored in a local Kerberos keytab file. Principal name and key pairs listed in the Kerberos keytab file allow services running on a host to authenticate themselves to the Kerberos Key Distribution Center (KDC). Before a server can use Kerberos, a Kerberos keytab file must be initialized on the host that runs the server.
Using the ktab command to manage the Kerberos keytab file.
The SPNEGO provider supplies the implementation of the SPNEGO authentication mechanism, located at...
$WAS_HOME/java/jre/lib/ext/ibmspnego.jar
The custom configuration properties control the runtime behavior of the SPNEGO TAI. Configuration operations are performed with the administrative console or scripting facilities.
JVM custom properties control diagnostic trace information for problem determination of the JGSS security provider and use of the property reload feature.
The benefits of having WAS use the SPNEGO TAI include:
- On Windows, an integrated single signon environment with Microsoft Windows 2000 or 2003 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 applications that use SPNEGO authentication at the transport level is achieved.
Using the SPNEGO TAI in your WAS environment requires planning then implementation.
Implementing the use of the SPNEGO TAI is divided into the following areas of responsibility:
- End browser user
- End user must configure the Web browser or Microsoft .NET application to issue HTTP requests that are processed by the SPNEGO TAI.
- Web administrator
- Responsible for configuring the SPNEGO TAI of WAS to respond to HTTP requests of the client.
- WAS administrator
- Responsible for configuring WAS and the SPNEGO TAI for optimum installation performance.
SPNEGO setup
- Create a single sign-on for HTTP requests using the SPNEGO TAI
- Set up the Kerberos configuration properties.
- Set or adjusting the SPNEGO TAI custom properties.
- Adjusting the SPNEGO TAI filter settings.
- Using the custom login module to map the identity from the AD to the WAS registry.
- Set the major and additional JVM custom properties.
Related concepts
Single sign-on
Related tasks
Creating a single sign-on for HTTP requests using the SPNEGO TAIMapping Kerberos client principal name to WebSphere user registry ID for SPNEGO
Related reference
Single sign-on capability with SPNEGO TAI - checklistUsing the ktab command to manage the Kerberos keytab file
Kerberos configuration file
SPNEGO TAI JVM configuration custom properties
SPNEGO TAI custom properties configuration
Related information
The Simple and Protected GSS-API Negotiation Mechanism (IEFT RFC 2478)Single Sign-on Using Kerberos in Java
Kerberos: The Network Authentication Protocol
SPNEGO TAI configuration requirements