Digipass Authentication for Tivoli Access Manager

Digipass Authenticationfor Tivoli Access Manager

Technical White Paper v1.1

Digipass Authentication for Tivoli Access Manager

Contents Contents ...........................................................................................................................................................................................................2 Preface ...............................................................................................................................................................................................................3 About TAM Authentication ..........................................................................................................................................................................4 About Vasco and Digipass authentication..................................................................................................................................................5 TAM and Digipass authentication ................................................................................................................................................................6 Token repository ............................................................................................................................................................................................8

Storing Vasco Digipass Token information ..........................................................................................................................................8 Repository fail-over ...................................................................................................................................................................................9 Security considerations.......................................................................................................................................................................... 10 Token initialisation.................................................................................................................................................................................. 10 The Digipass CDAS process................................................................................................................................................................. 11

Digipass CDAS features.............................................................................................................................................................................. 13 Functionality ............................................................................................................................................................................................. 13 Configuration ........................................................................................................................................................................................... 13

www.vasco.com ∙ Digipass Authentication for Tivoli Access Manager ∙ Version 1.1 ∙ 2

Preface

IBM Tivoli Access Manager (TAM) for e-business is the leading platform for access control to web-based applications. TAM supports a number of authentication mechanisms out-of-the-box and provides an interface for other types, called CDAS (Cross Domain Authentication Service). Based on years of experience in large Access Manager projects, SecurIT has developed its revolutionary C-Man™ concept, library classes and a methodology to speed-up the provision of such CDAS implementations according to the highest quality standards. VASCO Digipass® provides a strong two-factor authentication mechanism used by more than 800 organisations with over 8 million end-users around the world. For more information on VASCO Digipass: http://www.vasco.com SecurIT partners with IBM and VASCO to provide an interface between these products, based on this C-Man concept, in order to allow Digipass-based authentication to access enterprise applications. This paper contains a high-level overview of the architecture of the solution and how it integrates with TAM. The solution described in this document has been certified by IBM as “Ready for Tivoli Access Manager”.


About TAM Authentication TAM provides authentication and authorisation services for web based resources by means of a reversed proxy. This reversed proxy, called WebSEAL, sits between the end-user’s browser and the organization’s web servers. It intercepts HTTP requests and performs authentication and authorisation checks for protected resources. The following figure illustrates this process.

Build Credential

Brows TAM LDAP WebSEAL 5

Authentication Information Reversed Proxy

ExternalRegistry

1

Auth Info

TAM ID 2 4

External Authentication

Service

3 Authentication Module

(CDAS)

The first time a user requests a protected web resource, WebSEAL will challenge the user for authentication.

1. The user sends his authentication information by means of an HTTP request to WebSEAL

2. WebSEAL extracts the authentication information and forwards it to the CDAS module

3. The CDAS module verifies the authentication data against an external resource 4. The CDAS module passes the verified identity back to WebSEAL (or an

authentication failure message) 5. WebSEAL builds a valid internal credential for the user


Finally, WebSEAL uses this internal credential to validate the user’s request. WebSEAL provides out-of-the-box CDAS modules that deal with: • • •

• • •

Username/password authentication One-time password authentication for SecurID Client-side X.509 certificates

However, on top of this WebSEAL provides a developers toolkit for building custom CDAS modules. This toolkit has served as the basis for building the CDAS module that supports both Static and Dynamic Digipass authentication tokens.

About Vasco and Digipass authentication

Vasco secures the enterprise from the mainframe to the Internet with infrastructure solutions that enable secure e-business and e-commerce, protect sensitive information, and safeguard the identity of users. The company’s family of Digipass® and VACMAN® products offer end-to-end security through authentication, digital signature, and Radius and Web security, while sharply reducing the time and effort required to deploy and manage security. The Vasco Digipass product family consists of a set of hardware and software tokens that provide authentication and digital signature services. The following authentication mechanisms are supported:

Dynamic pincode Static + Dynamic pincode Challenge/Response

The VACMAN product family facilitates the integration of strong Digipass authentication into security-critical applications. One of the products in this family is the VACMAN Controller. It provides Digipass strong authentication and signatures mechanisms natively into any application, in the form of an API regardless of your preferred OS (Operating System) or communication protocol, database management system or GUI (Graphical User Interface), from PC to mainframe.


The integration between Digipass and TAM, as described in this paper, supports both dynamic and static + dynamic pincodes. It uses the VACMAN Controller API from within the CDAS module to verify the pincode. The following figure illustrates the combination of a Digipass token and the VACMAN Controller.

Fetch token Information Brows

Application UserID pincode

2

Authentication Code

Token Registry5

1 Write token Information UserID

PincodeToken

Token’ 3 4

VACMAN Controller API

1. The user retrieves his pincode from the token and enters it together with his user ID

into the application 2. The application fetches the corresponding token information from the registry 3. The application calls the Controller together with the token information and user

information 4. The Controller verifies the authentication information and updates the token

information 5. The application writes the updated token information into the registry

The selection of a token registry is an application matter.

TAM and Digipass authentication

This section describes the integration of Access Manager WebSEAL with Vasco Digipass tokens. This paper only contains a high level overview of the architecture and functionality. Fore more details we refer to the Digipass CDAS Installation and Administration Guide.


From a user’s perspective “User ID/pincode” authentication is very similar to username/password authentication. For this reasons it was decided to build the Digipass CDAS as a username/password CDAS where the username would hold the user ID associated with the token and the password would reflect the one-time password (dynamic or static + dynamic). The following figure illustrates the architecture of the solution.

TAM ID

Build Credential Brows

WebSEAL UserID Pincode

6

Reversed Proxy TAM LDAP

1

Fetch token Information

3

UserID Pincode 2 5

4

Authentication Module(Digipass CDAS) Write token

Information

1. The user retrieves his pincode from the token and enters it together with his user ID

into the username/password login form of WebSEAL 2. WebSEAL forwards the authentication information to the Digipass CDAS 3. The CDAS fetches the corresponding token information from the TAM LDAP

directory and verifies the authentication information 4. The CDAS write the updated token information into the TAM LDAP directory 5. The CDAS module passes the verified identity back to WebSEAL (or an

authentication failure message) 6. WebSEAL builds a valid internal credential for the user

This illustrates the basic process flow of Digipass authentication as carried out by the custom CDAS. There are however a couple of points that need more attention. • For token synchronisation and to avoid replay, the authentication server needs to keep

track of information associated with the token. This Digipass CDAS uses the LDAP directory for this purpose.


• Token authentication is often used in combination with username/password authentication. Therefore, the authentication server (CDAS) needs a mechanism to make a distinction between users holding a token and user authenticating using username/password.

These topics are described in slightly more detail below.

Token repository

Storing Vasco Digipass Token information As stated above, the Digipass CDAS uses the TAM LDAP Directory as its repository to store token information. In the current release both IBM LDAP and SunOne LDAP are supported. The token information is stored in an object that is located in a subtree under the user with whom the token is associated. The following screen dump shows such an entry.


The screen dump shows that the token with serial number 0097123456 is associated with the TAM user with DN (Distinguished Name) cn=Allowed1, o=sov, c=be. The CDAS makes absolutely no assumptions about the format of the DN, as long as it is accepted by TAM. The token information is stored as an instance of the Object Class sitVascoToken. The object is created under the secAuthority=Default entry created by TAM. A token entry basically contains the following information: • • • • • • •

sitVasco Type of the token (e.g. ResponseOnly) sitVascoApplName Application using the token sitVascoBlob The token details, aka. BLOB (contains e.g. current valid pincode) sitVascoDpFlags Token flag (internal use) sitVascoSerialNr Token serial number (to physically associate a token with a user) sitVascoMode Mode of operation (optional) sitVascoType Type of token (optional)

For more information on these attribute, please refer to Vasco documentation and/or the Digipass CDAS Installation & Administration Guide.

Repository fail-over Validation of the user’s pincode is done by the CDAS using the VACMAN Controller API. It is a stand-alone library that takes the user’s pincode and the BLOB that is currently associated with the user’s token. To avoid replay of pincodes and to allow for token synchronisation, the CDAS should always be able to get hold of the latest BLOB. Therefore, the Digipass CDAS foresees an LDAP fail-over mechanism. This mechanism is shown in the following figure:



TAM ID

Build Credential Brows

WebSEAL Slave TAM LDAP

UserID Pincode Master

TAM LDAP

Reversed Proxy

UserID Pincode Write token

Information Fetch tokenInformationAuthentication Module

(Digipass CDAS)

To make sure that the Digipass CDAS is always able to fetch the most up-to-date BLOB, it is able to talk in fail-over mode to LDAP. It will always try the first mentioned LDAP server first; if that server fails it will try the next LDAP, and so on until it has tried all known LDAP servers. If no working LDAP server can be found, the authentication request will fail. The CDAS should however also make sure that the updated BLOB gets written back to LDAP. As such it would be best practise to work with a multi-master LDAP cluster. However, as this is not always possible, the CDAS can be configured to continue with the authentication process even if it cannot write the BLOB back into LDAP. As long as this situation is not persistent, the token will be synchronised (if needed) at a later stage. Anyhow, the CDAS will also report BLOB update failures in its log file.

Security considerations The Digipass CDAS can be configured to talk LDAP over SSL with the LDAP servers. It will bind to LDAP using a (configurable) user with appropriate credentials to read and write the token information.

Token initialisation The Digipass CDAS comes with a command line tool for initialising tokens. This tool takes two input files • DPX file

•

• • • •

“TAM user to token” mapping file The DPX file is delivered by Vasco together with the tokens. It contains all the token related information that goes into the LDAP server. The second file contains an entry for each existing TAM user that needs a new or updated token. The tool basically generates the Digipass subentry as shown above.

The Digipass CDAS process The Digipass CDAS is fully in line with the CDAS specification as listed in the WebSEAL Developers Reference guide. This means that it supports the following functions:

xauthn_initialize() xauthn_shutdown() xauthn_authenticate() xauthn_change_password()

Although the Digipass CDAS can be used where step-up authentication is needed, it should be noted that in some cases the selection of the authentication mechanism is not necessarily controlled by the required authentication levels but merely by the fact that a user possesses a token or not. In such a case the Digipass CDAS can be configured to support both username/password and one-time password. This is controlled by setting the LDAP attribute employeeType, as shown by the following screen dump.


The current release of the Digipass CDAS supports the following values for the employeeType attribute: • • •

Username/password 1 Digipass response-only 2 Digipass challenge/response 3 (placeholder)

It should be noted that these are only the default settings. The LDAP attribute and the corresponding values are configurable.



Digipass CDAS features

This paragraph summarises the key features of the Digipass CDAS. For more details please refer to the Digipass CDAS Installation & Administration Guide and the Digipass Administration Tool User Guide.

Functionality • • • • • • • • • •

• • • • • • • •

Supports both username/password and Digipass one-time passwords Supports password change for username/password Supports static pincode change for one-time password Supports token synchronisation Supports token unlocking Compliant with Tivoli Access Manager 4.1 Supported both on Windows 2000 and Solaris Uses LDAP as token registry Supports both IBM LDAP and SunOne LDAP Provides token initialisation tool

Configuration Supports LDAP over SSL Configurable log level LDAP Master/Slave configuration Username/password authentication using BIND or COMPARE Configurable authentication method switch GSO to Extended Attributes mapping Configurable Vasco LDAP object and attributes Several configurable Digipass parameters

Digipass Authentication for Tivoli Access Manager

Documents

Transcript of Digipass Authentication for Tivoli Access Manager