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

Create 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 WAS.

Deprecated feature:

In WAS v6.1, a trust association interceptor (TAI) that uses the 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:

• A Microsoft Windows Server running the Active Directory Domain Controller and associated Kerberos Key Distribution Center (KDC). For information on the supported Microsoft Windows Servers, see the System Requirements for WebSphere Application Server v8.5 on Windows.

• A Microsoft Windows domain member (client) for example, a browser or Microsoft .NET client, that supports the SPNEGO authentication mechanism, as defined in IETF RFC 2478. Internet Explorer Version 5.5 or later and Mozilla Firefox Version 1.0 qualify as such clients.

  Important: A running domain controller and at least one client machine in that domain is required. Trying to use SPNEGO directly from the domain controller is not supported

• The domain member has users who can log on to the domain. Specifically, we need to have a functioning Microsoft Windows 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 WAS 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).

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.

Configure 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

1. 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:

   • Create a user account for the WAS 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 WAS 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, Create a Kerberos service principal and keytab file used by the WAS SPNEGO TAI (deprecated) 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, Create a Kerberos service principal and keytab file used by the WAS SPNEGO TAI (deprecated) has more details about using the ktpass command. to create the keytab file.

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

   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 WAS. The Kerberos keytab file contains the Kerberos service principal keys WAS 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 the web browser to use SPNEGO authentication. See Configure the client browser to use SPNEGO TAI (deprecated) for the detailed steps required for the 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 Configure the Lightweight Third Party Authentication mechanism for more details.

   • Enable the SPNEGO TAI. See Configure WebSphere Application Server and enabling the SPNEGO TAI (deprecated) for more details.

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

     • For using wsadmin task, see

       • SpnegoTAICommands group (AdminTask) (deprecated)

     • For using the console, see Configure WebSphere Application Server and enabling the SPNEGO TAI (deprecated) for more details.

   • Configure JVM properties and enable the SPNEGO TAI in Application Server in which it is defined. See Configure JVM custom properties, filtering HTTP requests, and enabling SPNEGO TAI in WebSphere Application Server (deprecated) or Enable the SPNEGO TAI as JVM custom property (deprecated) for more details.

   • Install the Kerberos keytab file (created in step 1) on the WAS machine. Create a Kerberos service principal and keytab file used by the WAS SPNEGO TAI (deprecated) provides the details.

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

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

4. Optional: Use a remote HTTP server - To use a remote server, you must complete the following steps, which assume that we 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).

   1. Complete the steps in Create a Kerberos service principal and keytab file used by the WAS SPNEGO TAI (deprecated) for the remote proxy server.

   2. Merge the previous keytab file created in step 1 with the keytab file created in step 4a. See Use the ktab command to manage the Kerberos keytab file for more information.

   3. Create the SPN for the remote proxy server using the addSpnegoTAIProperties wsadmin command task. For more information, see SpnegoTAICommands group (AdminTask) (deprecated).

   4. Restart the WAS.

Subtopics

• Single sign-on for HTTP requests using SPNEGO TAI (deprecated)
  WebSphere Application Server provides a trust association interceptor (TAI) that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources in WebSphere Application Server.

• (dist) Create a Kerberos service principal and keytab file used by the WAS SPNEGO TAI (deprecated)
  You perform this configuration task on the Microsoft Active Directory domain controller machine. This task is a necessary part of preparing to process single sign on browser requests to WebSphere Application Server and thee SPNEGO trust association interceptor (TAI).

• (dist) Configure WebSphere Application Server and enabling the SPNEGO TAI (deprecated)
  Performing this task helps you, as web administrator, to ensure that WebSphere Application Server is properly configured to enable the operation of the Simple and Protected GSS-API Negotiation (SPNEGO) trust association interceptor (TAI).

• (dist) Configure the client browser to use SPNEGO TAI (deprecated)
  We can configure the browser to utilize the Simple and Protected GSS-API Negotiation (SPNEGO) mechanism. Authentication of the browser requests are processed by the SPNEGO trust association interceptor (TAI) in the WAS.

• (dist) Configure JVM custom properties, filtering HTTP requests, and enabling SPNEGO TAI in WebSphere Application Server (deprecated)
  Performing this task helps you, as web administrator, to ensure that WebSphere Application Server is configured to enable the operation of the Simple and Protected GSS-API Negotiation mechanism (SPNEGO) trust association interceptor (TAI) with the required JVM property and with the appropriate filtering of HTTP requests.

• (dist) Mapping Kerberos client principal name to WebSphere user registry ID for SPNEGO TAI (deprecated)
  We can use a system programming interface to customize the behavior of the SPNEGO trust association interceptor (TAI) by implementing arbitrary mappings of the end-user's identity, which is retrieved from Microsoft Active Directory to the identity used in the WAS security registry.

• Single sign-on capability with SPNEGO TAI - checklist (deprecated)
  WebSphere Application Server provides a trust association interceptor (TAI) that uses the SPNEGO to securely negotiate and authenticate HTTP requests for secured resources in WebSphere Application Server. To deploy and use the SPNEGO TAI we need to examine your installation and decide on how best to configure the SPNEGO TAI.

• (dist) Filtering HTTP requests for SPNEGO TAI (deprecated)
  We can use a system programming interface to customize the behavior of the SPNEGO trust association interceptor (TAI) by specifying whether or not a particular HTTP request should be intercepted.

Related tasks

Implement single sign-on to minimize web user authentications

Enable the SPNEGO TAI as JVM custom property (deprecated)

Configure the Lightweight Third Party Authentication mechanism

SPNEGO TAI JVM configuration custom properties (deprecated)

SPNEGO TAI custom properties configuration (deprecated)

Use the ktab command to manage the Kerberos keytab file