Creating single sign-ons for HTTP requests using the Simple and
Protected GSS-API Negotiation Mechanism (SPNEGO) trust association interceptor
(TAI) for WebSphere® Application
Server requires the performance of several distinct, yet related functions
that when completed, allow HTTP users to log in and authenticate only once
at their desktop and receive automatic authentication from the WebSphere Application
Server.
Before you begin
Deprecated feature: In WebSphere Application Server Version
6.1, a trust association interceptor (TAI) that uses the Simple and Protected
GSS-API Negotiation Mechanism (SPNEGO) to securely negotiate and authenticate
HTTP requests for secured resources was introduced. In WebSphere Application Server 7.0,
this function is now deprecated. SPNEGO Web authentication has taken its place
to provide dynamic reload of the SPNEGO filters and to enable fallback to
the application login method.
depfeat
Before starting this task, complete
the following checklist:
About this task
The objective of this machine arrangement is to permit users to
successfully access WebSphere Application Server resources without
having to reauthenticate and thus achieve Microsoft Windows desktop single sign-on capability.
Configuring
the members of this environment to establish Microsoft Windows single sign-on involves specific
activities that are performed on three distinct machines:
- Microsoft Windows 2000
or Windows 2003
Server running the Active Directory Domain Controller and associated Kerberos
Key Distribution Center (KDC)
- A Microsoft Windows 2000
or Windows 2003
domain member (client application), such as a browser or Microsoft .NET
client.
- A server platform with WebSphere Application Server running.
Perform the following steps on the indicated machines to create
single sign-on for HTTP requests using SPNEGO
Procedure
- Domain Controller Machine - Configure the Microsoft Windows 2000
or Windows 2003
Server running the Active Directory Domain Controller and associated Kerberos
Key Distribution Center (KDC) This configuration activity has the
following steps:
Important: Your domain controller operations must lead to
the following results:
- A user account is created in the Microsoft Active Directory and mapped
to a Kerberos service principal name.
- A Kerberos keytab file (krb5.keytab) is created and made available
to the WebSphere Application
Server. The Kerberos keytab file contains the Kerberos service principal keys WebSphere Application
Server uses to authenticate the user in the Microsoft Active Directory and the
Kerberos account.
- Client Application Machine - Configure the client application.
Client-side applications are responsible for generating the SPNEGO token
for use by the SPNEGO TAI. You begin this configuration process by configuring
your Web browser to use SPNEGO authentication. See Configuring the client browser to use SPNEGO TAI (deprecated) for the detailed steps required for your browser.
- WebSphere Application
Server Machine - Configure and enable the Application Server and the associated
SPNEGO TAI by performing the following tasks:
- Optional: Using a remote HTTP server - To use
a remote server, you must complete the following steps, which assume that
you have already configured the JVM properties and enabled the SPNEGO TAI
in the Application Server in which it is defined (as described in the previous
three steps).
- Complete the steps in Creating a Kerberos service principal and keytab file that is used by the WebSphere Application Server SPNEGO TAI (deprecated) for the remote proxy server.
- Merge the previous keytab file created in step 1 with the keytab
file created in step 4a. See Using the ktab command to manage the Kerberos keytab file for
more information.
- Create the SPN for the remote proxy server using the addSpnegoTAIProperties
wsadmin command task. For more information, see SpnegoTAICommands group for the AdminTask object (deprecated).
- Restart the WebSphere Application Server.