Create a single sign-on for HTTP requests using the SPNEGO TAI

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 starting this task, complete the following checklist:

• The domain member has users who can log on to the domain. Specifically, you need to have a functioning Microsoft Windows 2000 or Windows 2003 active directory domain that includes:

  • Domain controller

  • Client workstation

  • Users who can login to the client workstation

• A server platform with WebSphere Application Server running and application security enabled.

• Users on the active directory must be able to access WebSphere Application Server protected resources using a native WebSphere Application Server authentication mechanism.

• The domain controller and the host of WebSphere Application Server should have the same local time.

• Ensure the clock on clients, Microsoft Active Directory and WebSphere Application Server are synchronized to within five minutes.

• Be aware that client browsers have to be SPNEGO enabled, which you perform on the client application machine (with details explained in step 2 of this task).

Overview

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’s Windows 2000 or Windows 2003 Server running the Active Directory Domain Controller and associated Kerberos Key Distribution Center (KDC)

• A Microsoft’s Windows 2000 or Windows 2003 domain member (client application), such as a browser or .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

1. Domain Controller Machine - Configure the Microsoft’s 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:

   • Create a user account for the WebSphere Application Server in a Microsoft Active Directory. This account will be eventually mapped to the Kerberos service principal name (SPN).

   • On the Microsoft Active Directory machine where the Kerberos key distribution center (KDC) is active, map the user account to the Kerberos service principal name (SPN). This user account represents the WebSphere Application Server as being a Kerberize'd service with the KDC. Use the setspn command to map the Kerberos service principal name to a Microsoft user account. The topic, Creating a Kerberos service principal and keytab file that is used by the WebSphere Application Server SPNEGO TAI has more details about using the setspn command.

   • Create the Kerberos keytab file and make it available to WebSphere Application Server. Use the ktpass tool to create the Kerberos keytab file (krb5.keytab). The topic, Creating a Kerberos service principal and keytab file that is used by the WebSphere Application Server SPNEGO TAI has more details about using the ktpass command. to create the keytab file.

     Note: You make the keytab file available to WebSphere Application Server by copying the krb5.keytab file from the Domain Controller (LDAP machine) to the WebSphere Application Server machine. See Using the ktab command to manage the Kerberos keytab file for more details.

   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.

2. 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 for the detailed steps required for your browser.

3. WebSphere Application Server Machine - Configure and enable the Application Server and the associated SPNEGO TAI by performing the following tasks:

   • Ensure that LTPA is enabled. See Configuring the Lightweight Third Party Authentication mechanism for more details.

   • Enable the SPNEGO TAI. See Configuring WebSphere Application Server and enabling the SPNEGO TAI for more details.

   • Create SPNEGO TAI properties using either the wsadmin command task or the administrative console.

     • For using the wsadmin command task, see

       • SpnegoTAICommands group for the AdminTask object

     • For using the administrative console, see Configuring WebSphere Application Server and enabling the SPNEGO TAI for more details.

   • Configure JVM properties and enable the SPNEGO TAI in Application Server in which it is defined. See Configuring JVM custom properties, filtering HTTP requests, and enabling SPNEGO TAI in WebSphere Application Server or Enabling the SPNEGO TAI as JVM custom property using scripting for more details.

   • Install the Kerberos keytab file (created in step 1) on the WebSphere Application Server machine. Creating a Kerberos service principal and keytab file that is used by the WebSphere Application Server SPNEGO TAI provides the details.

   • Create a basic Kerberos configuration file (krb5.ini or krb5.conf). See Kerberos configuration file for details.

   • Map the client Kerberos principal name to the WebSphere user registry ID, but only if the WebSphere Application Server does not use Micorsoft Active Directory. See Mapping Kerberos client principal name to WebSphere user registry ID for SPNEGO for more details.

Related tasks

Related Reference