+

Search Tips   |   Advanced Search

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:

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:

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:

    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:

  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


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