Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

118 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

Failover cookies do not have to be implemented in an environment with a

Session Management Server since the failover cookie takes responsibility for

maintaining a user session.

4.3.5 Authentication with RSA SecurID token

Access Manager supports authentication of clients using user name and token

pass code information from an RSA SecurID token authenticator (TAR), a

physical device that stores and dynamically generates a piece of authentication

data (a token).

The TAR is used in tandem with an authentication server (the RSA ACE/Server),

which actually performs the authentication. During authentication to WebSEAL,

the client enters a user name and pass code. The pass code consists of:

򐂰 The unique PIN number associated with the client’s SecurID TAR

򐂰 The current number sequence generated by the SecurID TAR

The Ace/Server uses its own registry database to determine the PIN that the

user should be using, checks it, and strips it off of the pass code. It then checks

the remaining number sequence against its own internally generated number

sequence. A matching number sequence completes the authentication.

At this point, the role of the token passcode authentication is complete. The

token passcode authentication does not perform identity mapping, but simply

returns to WebSEAL an Access Manager identity containing the user name of

the client. This user name must match a user ID stored in the Access Manager

user registry.

4.3.6 Windows desktop single sign-on (SPNEGO)

Before describing Windows desktop single sign-on, there are some important

security considerations to point out:

򐂰 In order for Microsoft Internet Explorer (IE) to be able to use the integrated

Windows authentication, it must recognize the Access Manager server as an

Intranet or Trusted site. The Internet Explorer client must be configured to use

the SPNEGO protocol and Kerberos authentication when contacting

WebSEAL or the Web Server Plug-in.

򐂰 WebSEAL or the Web Server Plug-in must be able to access Active Directory

as its Kerberos Key Distribution Center (KDC). This may expose Active

Directory to new networks.

Therefore, it is important to only use SPNEGO authentication over a secure

network or over a secure transport. WebSEAL and the Web Server Plug-in

support the SPNEGO (Simple and Protected GSS-API Negotiation) protocol and

Chapter 4. Configuration and customization 119

Kerberos authentication for use with Windows clients to achieve Windows

desktop single sign-on. The SPNEGO protocol allows for a negotiation between

the client (browser) and the server regarding the authentication mechanism to

use. The client identity presented by the browser can be verified by WebSEAL or

the Web Server Plug-in using Kerberos authentication mechanisms.

WebSEAL SPNEGO support provides single sign-on from Internet Explorer

running on Windows client workstations configured into an Active Directory

domain.

For the WebSEAL SPNEGO configuration it is not necessary for Access

Manager to use Microsoft Active Directory as the user registry. When Active

Directory is

not the Tivoli Access Manager user registry, users must be replicated

between the client Active Directory registry and the Tivoli Access Manager user

registry.

Mapping an ID from Active Directory to Access Manager is an important part of

SPNEGO. Normally, WebSEAL will truncate the domain name portion of an

Active Directory ID in order to get the user ID. This can cause conflicts, however,

if two different users have the same ID in different Active Directory domains. In

this case, WebSEAL would need to be configured to keep the domain section of

the user ID attached in order to be able to resolve the conflict.

Multiple Active Directory domain support

Active Directory uses domains and forests to represent the logical structure of the

directory hierarchy. Domains are used to manage the various populations of

Important: The use of SPNEGO requires that a time synchronization service

be deployed across the Active Directory server, the WebSEAL server or the

Web Server Plug-in, and any clients that will authenticate using SPNEGO.

Note: SPNEGO single sign-on support is also available on other platforms,

including:

򐂰 IBM AIX

򐂰 Windows

򐂰 Solaris

򐂰 Linux x86

򐂰 Linux for S/390®

More technical information on how to integrate Linux desktop single sign-on

and the Mozilla Firefox browser can be found in the IBM Redbook Federated

Identity Management and Web Services Security with IBM Tivoli Security

Solutions, SG24-6394.