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
Before starting this task, complete the following checklist:
Supported configurations: The following scenarios
are supported for a SPNEGO TAI with a browser client:
- Cross-forest trust
- Domain trust within the same forest
- Kerberos realm trust
The following scenarios are not
supported for a SPNEGO TAI with a browser client:
- Forest external trust
- Domain external trust
The following scenarios are supported for a SPNEGO TAI
with a Java client using the HTTP protocol:
- Domain trust within the same forests
- External domain trust directly between domains within different
forests
- Kerberos realm trust
The following scenarios are not supported for a SPNEGO
TAI with a Java client using the HTTP protocol:
- Cross-forest trust
- Forest external trust
sptcfg
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:
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) ![[Updated in February 2011]](../../deltaend.gif)
feb2011
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 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 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 ktutil 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.
- Restart the WebSphere Application Server.