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 Server running the Active Directory Domain Controller and associated
Kerberos Key Distribution Center (KDC)
- A Microsoft Windows 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 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.