Вы находитесь на странице: 1из 49

IDENTIKEY ® Authentication Server

Performance and Deployment Guide

3.10

Disclaimer of Warranties and Limitations of Liabilities

Intellectual Property

VASCO Software, documents and related materials (“Materials”) made available on the Site contain pro- prietary and confidential information. All title, rights and interest in VASCO Software and Materials, updates and upgrades thereof, including software rights, copyrights, patent rights, trade secret rights, sui generis database rights, and all other intellectual and industrial property rights, vest exclusively in VASCO or its licensors. No VASCO Software or Materials published in this Site may be downloaded, copied, transferred, disclosed, reproduced, redistributed, or transmitted in any form or by any means, electronic, mechanical or otherwise, for any commercial or production purpose, except as otherwise marked or when expressly permitted by VASCO in writing.

Disclaimer

VASCO accepts no liability for the accuracy, completeness, or timeliness of Site content, or for the reli- ability of links to and content of external or third party websites.

VASCO shall have no liability under any circumstances for any loss, damage, or expense incurred by you, your company, or any third party arising from the use or inability to use VASCO Software or Mater- ials, or any third party material available or downloadable from the Site. VASCO will not be liable in rela- tion to any loss/damage caused by modification of these Legal Notices or Site content.

Reservation

VASCO reserves the right to modify these Notices and the content at any time. VASCO likewise reserves the right to withdraw or revoke consent or otherwise prohibit use of the VASCO Software or Materials if such use does not conform to the terms of any written agreement between VASCO and you, or other applicable terms that VASCO publishes from time to time.

Trademarks

VASCO ® , VACMAN ® , IDENTIKEY ® , aXsGuard ® , DIGIPASS ® , CertiID ® , CRONTO™, CRONTOSIGN™, MYDIGIPASS.COM™, the MYDIGIPASS.COM MD Lock logo, the DP+ logo, the VASCO ‘V’ logo, and the Cronto logo are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries.

VASCO reserves all rights to the trademarks, service marks and logos of VASCO and its subsidiaries.

Copyright

Copyright © 2008–2016 VASCO Data Security, Inc., VASCO Data Security International GmbH. All rights reserved.

Date last modified: 6/27/2016

Table of Contents

Table of Contents

1. Introduction

8

1.1. Who should read this guide?

 

8

1.2. IDENTIKEY Authentication Server Documentation Suite

 

8

1.3. Factors Affecting IDENTIKEY Authentication Server Performance

9

2. Deployment Models

 

10

2.1. Basic Deployment Model

 

11

2.2. Advanced Deployment Model

 

13

2.3. High Availability Deployment Model

 

15

2.4. Maximum Availability Deployment Model

 

17

2.5. WAN Deployment Model

 

20

2.6. Network Hardware Security Module Deployment Model

 

22

2.7. Internal Hardware Security Module Deployment Model

 

24

3. Deployment Considerations

 

27

3.1. Load Balancing

 

27

3.2. Rolling Upgrades

 

31

3.3. Domain Considerations for ODBC Deployments

 

31

4. Active Directory Deployment Considerations

 

33

4.1. Active Directory Permissions

 

33

4.2. Active Directory Replication Issues

 

33

4.3. IDENTIKEY Authentication Server and Multiple Domains

 

37

4.4. Assigning DIGIPASS Permissions to a Group

 

39

5. Audit and Report Performance

 

41

5.1. Recommendations for Basic and Advanced Deployment Models

41

5.2. Recommendations for High

Availability Deployment Models

 

42

5.3. Additional Audit and Report Considerations

 

42

Table of Contents

6.

Performance Baselines

 

43

6.1. Performance Test Setup

 

43

6.2. Software Environments

 

45

6.3. Results

 

47

6.4. Variations

 

48

6.5. Recommendations

 

48

APPENDIX

 

49

Appendix.1. Adding Indexing for Report Performance

49

Table Index

Table of Contents

Table 1:

Deployment models

10

Table 2:

Software environments used for testing

 

46

Table 3: Import records results

 

47

Table 4:

Authentication results, in auths/sec (no reporting)

47

Illustration Index

Table of Contents

Image 1: Basic deployment model

 

11

Image 2:

Advanced deployment model

 

13

Image 3: High-Availability deployment model

 

15

Image 4: Maximum-Availability deployment model

 

17

Image 5:

WAN deployment model

 

20

Image 6:

Network HSM deployment model

 

22

Image 7:

Internal Hardware Security Module deployment model

 

24

Image 8: SSL Tunneling (load balancing method)

 

29

Image 9: SSL Bridging (load balancing method)

 

30

Image 10: Domains and Organizational Units

 

32

Image 11: Relationship between IDENTIKEY Authentication Server, Database Servers, and SAN Server

45

Procedure Index

Table of Contents

Procedure 1:

Advanced Deployment Model setup

 

14

Procedure 2: High-Availability Deployment Model setup

 

16

Procedure 3: Maximum-Availability Deployment Model setup

19

Procedure 4:

WAN Deployment Model setup

21

Procedure 5:

Network HSM Deployment Model setup

 

23

Procedure 6:

Internal HSM Deployment Model setup

 

26

Procedure 7:

Assigning DIGIPASS Permissions to a Group

 

39

1. Introduction

1. Introduction

The IDENTIKEY Authentication Server Performance and Deployment Guide provides information on common ODBC deployment models and performance statistics.

Note This guide does not cover Active Directory deployments with the same level of detail as ODBC deployments. However, some information relevant to Active Directory deployments is available in the APPENDIX for reference.

1.1. Who should read this guide?

This guide is designed for system managers, administrators, and developers using IDENTIKEY Authentication Server products. The reader should already be familiar with:

n

Online authentication and authorization tools and protocols, including SOAP, RADIUS, WSDL, SSL, XML, HTML and TCP/IP.

n

Windows and Linux security software environments including IIS, Active Directory and ODBC.

n

Administration tasks including user management , policy, scheduling, reports, and performance mon- itoring.

n

Password management and encryption techniques.

n

EMV-CAP and other e-commerce transaction standards.

An understanding of programming languages, especially Java and ASP.NET, would also be helpful.

1.2. IDENTIKEY Authentication Server Documentation Suite

The following IDENTIKEY Authentication Server guides are available:

n

IDENTIKEY Authentication Server Product Guide: introduces the features and concepts of IDENTIKEY Authentication Server and explains various usage options.

n

IDENTIKEY Authentication Server Getting Started Guide: provides a walkthrough on deploying a standard setup of IDENTIKEY Authentication Server and testing its key features.

n

IDENTIKEY Authentication Server Windows Installation Guide: provides comprehensive instructions on installing IDENTIKEY Authentication Server on a Windows platform.

n

IDENTIKEY Authentication Server Linux Installation Guide: provides comprehensive instructions on installing IDENTIKEY Authentication Server on a supported Linux distribution.

n

IDENTIKEY Authentication Server Administrator Guide: in-depth information on the administration and man- agement of IDENTIKEY Authentication Server.

n

IDENTIKEY Authentication Server Administrator Reference: detailed IDENTIKEY Authentication Server ref- erences, including data attributes, utility commands, schema information, and other related information.

n

IDENTIKEY Authentication Server Performance and Deployment Guide: information on common deploy- ment models and performance statistics.

n

IDENTIKEY Authentication Server Release Notes: latest information on corresponding IDENTIKEY Authentic- ation Server releases.

1. Introduction

n

IDENTIKEY Authentication Server SDK Programmer's Guide: information on the IDENTIKEY Authentication Server Software Development Kit (SDK), with dedicated guides for .NET, Java, and SOAP:

 

n

IDENTIKEY Authentication Server SDK Programmer's Guide for .NET

n

IDENTIKEY Authentication Server SDK Programmer's Guide for Java

n

IDENTIKEY Authentication Server SDK SOAP Reference

n

IDENTIKEY Authentication Server SDK Plug-In Engine Guide

n

IAS Authentication SDK Programmer's Guide: in-depth information required to develop using the IAS Authentication SDK, with dedicated guides for .NET, Java, and SOAP:

 

n

IAS Authentication SDK Programmer's Guide for .NET

n

IAS Authentication SDK Programmer's Guide for Java

n

IAS Authentication SDK SOAP Reference

1.2.1. Further assistance

Comprehensive Help Files including context-sensitive assistance are available via IDENTIKEY Authentication Server user interfaces. For more information, please visit http://www.vasco.com.

1.3. Factors Affecting IDENTIKEY Authentication Server Performance

Some elements which will affect performance in IDENTIKEY Authentication Server are:

n

Machine specifications: refer to the System Requirements in the IDENTIKEY Authentication Server Win- dows Installation Guide or IDENTIKEY Authentication Server Linux Installation Guide.

n

Data store type, and location(s): refer to 2. Deployment Models for more information.

n

Data replication method: refer to the Replication section of the IDENTIKEY Authentication Server Admin- istrator Guide for more information.

n

Load balancing and failover options: refer to 2. Deployment Models for more information.

n

Auditing method: Auditing to database is encouraged as this will speed up both the auditing and reporting processes. Auditing to file is available but will produce significant processing overheads for reporting, as reporting can only be performed from a database.

n

Authentication protocol

n

Tracing enabled or disabled

2.

Deployment Models

2.

Deployment Models

An IDENTIKEY Authentication Server installation may be utilized for:

n

Authentication

n

Signature validation

n

Auditing

n

Co-ordinating distribution of DIGIPASS (provisioning)

n

Administration of data, configuration and authentication settings

n

Reporting

In larger systems, single IDENTIKEY Authentication Server instances may be assigned specific tasks – for example, one to handle authentication requests, another to handle provisioning and administration, still another for auditing and reporting tasks. Refer to the Scenarios section of the IDENTIKEY Authentication Server Product Guide for more information.

A number of options are available to scale IDENTIKEY Authentication Server to the level of operability, availability and performance required by your company.

Five basic deployment models are covered in this guide. The deployment model which will apply best to your situ- ation depends on these basic factors:

n

Number of Users in the system

n

Amount of authentication traffic

n

Number of sites needing authentication

n

System availability required – how important is it that authentication requests be processed immediately?

See the table below for a summary.

Table 1: Deployment models

Deployment Model

Number of Users

Authentications

Number of sites

System avail-

per second

ability required

Basic

< 50

< 50

1

Normal

Advanced

50

– 20 000

< 50

1

Normal

High Availability

100 – 50 000

> 50

1

High

Maximum Availability

< 2 000 000

> 100

1

Critical

WAN

50

– 2 000 000

< 50

multiple

High

Network HSM

50

– 2 000 000

<50

1

Normal

Internal HSM

50

– 2 000 000

>50

1

Normal

Note This chapter is ODBC storage specific.

2.

Deployment Models

2.1. Basic Deployment Model

2. Deployment Models 2.1. Basic Deployment Model Image 1: Basic deployment model The Basic deployment model

Image 1: Basic deployment model

The Basic deployment model is intended for small, low-demand situations, such as a small company local net- work or an evaluation of IDENTIKEY Authentication Server.

IDENTIKEY Authentication Server

A single IDENTIKEY Authentication Server installation, which handles authentication, auditing and admin- istration tasks. It uses the embedded PostgreSQL database as its data store.

Administration

Administration is performed on the server. It is recommended that import procedures be scheduled for off- peak authentication times, to reduce the load on the server.

Replication

No replication required.

2.

Deployment Models

Auditing

During a basic IDENTIKEY Authentication Server installation, the embedded PostgreSQL is installed. When this embedded database is installed, the default audit method will be ODBC Database. IDENTIKEY Authentication Server will automatically configure DSN according to the settings used during installation.

Reporting

When the embedded PostgreSQL database is installed, IDENTIKEY Authentication Server will automatically be configured to retrieve information from the same ODBC Database used for auditing. Refer to the Reporting section of the IDENTIKEY Authentication Server Administrator Guide for more information.

Deployment Steps

Install IDENTIKEY Authentication Server using the Basic installation option. This will also install and set up an Apache Tomcat web server, the Administration Web Interface, and an embedded PostgreSQL database.

Limitations

No failover support or data replication included. Recovery time from any machine or data problems may be extensive.

Note This chapter is ODBC storage specific.

2.

Deployment Models

2.2. Advanced Deployment Model

2. Deployment Models 2.2. Advanced Deployment Model Image 2: Advanced deployment model The Advanced deployment model

Image 2: Advanced deployment model

The Advanced deployment model is an extension of the Basic model, with better backup and availability. The primary IDENTIKEY Authentication Server may be dedicated exclusively to authentication requests, using none of its work time on administrative tasks. If the primary server fails, the backup server may be substituted with min- imal effort, as replication will have kept the data up to date.

IDENTIKEY Authentication Servers

This model features two IDENTIKEY Authentication Server installations:

n

1 primary, dedicated to handling authentication requests

n

1 backup, available for authentication requests if required, used for administration

Administration

Administration is linked to the backup server.

2.

Deployment Models

Replication

2-way replication enabled on both IDENTIKEY Authentication Server. Refer to the Replication section of the IDENTIKEY Authentication Server Administrator Guide for more information.

Auditing

Auditing to database on both servers. Refer to the Auditing sections of the IDENTIKEY Authentication Server Product Guide and IDENTIKEY Authentication Server Administrator Guide for more information.

Reporting

Reporting should be configured via the reporting scenario options in the configuration utility or via the Admin- istration Web Interface. Reports should be run from the Auditing databases.

Limitations

Note If you are running Replication using the Advanced Deployment Model on machines which are permanently under load, it is strongly advised that you configure Replication using the Maximum Availability Deployment Model. Slow responses from the IDENTIKEY Authentication Servers under load will disrupt the Replication process.

Procedure 1: Advanced Deployment Model setup

1. Install IDENTIKEY Authentication Server on primary machine.

2. Install IDENTIKEY Authentication Server on backup machine.

3. Install Administration Web Interface on the backup server.

4. Configure 2-way replication on each IDENTIKEY Authentication Server instance.

Optional: disable administration scenario on primary server.

5. Schedule making data available for reporting.

6. Make auditing data available for reporting – schedule merge of primary server's audit data with backup server auditing data using Maintenance Wizard.

Note This chapter is ODBC storage specific.

2.

Deployment Models

2.3. High Availability Deployment Model

Deployment Models 2.3. High Availability Deployment Model Image 3: High-Availability deployment model The

Image 3: High-Availability deployment model

The High-Availability deployment model is an example of a system with higher performance and greater avail- ability.

Performance

Higher performance is achieved with the use of load-balancing in client-side applications, between two primary IDENTIKEY Authentication Server. Database load sharing to dedicated database servers is configured in each IDENTIKEY Authentication Server. A dedicated audit database is used for auditing and reporting. Administration is performed via the backup IDENTIKEY Authentication Server, cutting down pressure on the primary servers.

2.

Deployment Models

Availability

Availability of the system is increased by the configuration of failover and failback between IDENTIKEY Authentication Server, and the use of a backup database server.

Note

Client side load-balancing and fail-over is built in into the client application in this type of deployment.

IDENTIKEY Authentication Servers

Two primary IDENTIKEY Authentication Server instances and one backup IDENTIKEY Authentication Server.

Data stored on dedicated database servers.

Administration

All administrative operations are performed on the backup server.

Long running operations taking quite some time can be performed with no direct impact on the authen- tication server performance handling authentication requests (these administrative operations will introduce only a replication impact on the commercial database servers).

Administration scenario could be disabled on both primary servers to exclude administrative load. This is done via the Administration Web Interface.

Replication

Custom database replication used. IDENTIKEY Authentication Server replication is not enabled.

Auditing

Auditing data should be written to databases at each site, and the data imported to the master auditing data- base at the administration site on a regular basis.

Reporting

Refer to the Reporting section of the IDENTIKEY Authentication Server Administrator Guide for more inform- ation.

Procedure 2: High-Availability Deployment Model setup

1. Install a commercial database on each dedicated database server, and modify the schema accordingly.

2. Set up replication between the databases.

3. Install IDENTIKEY Authentication Server on each primary server and the backup server, using the Advanced installation option.

4. Configure database load sharing on each IDENTIKEY Authentication Server.

5. Install a database on the audit server.

6. Set up auditing as required.

7. Configure reporting as required.

2.

Deployment Models

8. Schedule making data available for reporting - merge of primary servers audit files with backup server auditing information using the Maintenance Wizard.

Note This chapter is ODBC storage specific.

2.4. Maximum Availability Deployment Model

storage specific. 2.4. Maximum Availability Deployment Model Image 4: Maximum-Availability deployment model The Maximum-

Image 4: Maximum-Availability deployment model

The Maximum- Availability deployment model increases performance and availability by introducing greater backup measures and adding a dedicated third-party load balancer application.

2.

Deployment Models

Performance

Higher performance is achieved with the use of the third-party load balancer directing authentication requests to two primary IDENTIKEY Authentication Server. Database load sharing to dedicated database servers is con- figured in each IDENTIKEY Authentication Server. A dedicated audit database is used for auditing and report- ing. Administration is performed via the backup IDENTIKEY Authentication Server, cutting down pressure on the primary servers.

Availability

Availability of the system is maximised by allowing the third-party load balancer to handle load balancing and failover/failback between primary IDENTIKEY Authentication Servers. Additionally, each primary IDENTIKEY Authentication Server is configured to failover to a backup IDENTIKEY Authentication Server.

A backup database server is in use, and each IDENTIKEY Authentication Server is configured to connect to it automatically if the primary database server is not available.

IDENTIKEY Authentication Servers

Two primary IDENTIKEY Authentication Servers, two backup IDENTIKEY Authentication Servers, one dedicated administration, auditing and reporting IDENTIKEY Authentication Server.

Data is stored on dedicated database servers.

Administration

All administrative operations are performed on the administration server.

Long running operations taking quite some time can be performed with no direct impact on the authen- tication server performance handling authentication requests (these administrative operations will introduce only a replication impact on the commercial database servers)

Administration scenario could be disabled on both primary servers and backup servers to exclude admin- istrative load. This is done via the Administration Web Interface.

Replication

Commercial replication enabled between database servers. IDENTIKEY Authentication Server replication dis- abled.

Auditing

Auditing data should be written to databases at each site, and the data imported to the master auditing data- base at the administration site on a regular basis.

2.

Deployment Models

Reporting

Reporting is best configured to retrieve auditing input from database for increased report generation through- put. For more information, refer to the Reporting section of the IDENTIKEY Authentication Server Administrator Guide.

Procedure 3: Maximum-Availability Deployment Model setup

1. Install commercial database on each dedicated database server, and modify the schema as needed.

2. Set up replication between the databases.

3. Install IDENTIKEY Authentication Server on each primary and backup server, using the Advanced install- ation option.

4. Configure database load sharing on each IDENTIKEY Authentication Server.

5. Install a database on the audit server.

6. Set up auditing as required.

7. Configure reporting as required.

8. Make auditing data available for reporting – schedule merge of primary server's audit data with backup server auditing data using Maintenance Wizard application.

Note This chapter is ODBC storage specific.

2.

Deployment Models

2.5. WAN Deployment Model

2. Deployment Models 2.5. WAN Deployment Model Image 5: WAN deployment model The WAN deployment model

Image 5: WAN deployment model

The WAN deployment model illustrates an multi-site deployment of IDENTIKEY Authentication Server, with data reg- ularly replicated between sites. Administration and reporting is handled in a single location. Other sites handle only authentication, validation and provisioning requests.

IDENTIKEY Authentication Servers

One primary/backup pair of IDENTIKEY Authentication Servers on each non-administration site.

Data is stored in a commercial database on a dedicated database server at each site.

Failover is configured on each primary IDENTIKEY Authentication Server for authentication requests only.

One administration site with a dedicated IDENTIKEY Authentication Server for administration and reporting – Administration Web Interface installed.

2.

Deployment Models

All primary commercial database servers replicating with each other and with the backup database server.

Dedicated database server for auditing data.

Administration

All administrative operations are performed on the administration server.

Long running operations taking quite some time can be performed with no direct impact on the authen- tication server performance handling authentication requests (these administrative operations will introduce only a replication impact on the commercial database servers).

Administration scenario could be disabled on both primary servers and backup servers to exclude admin- istrative load. This is done via the Administration Web Interface.

Replication

Custom database replication used over the Virtual Private Network. IDENTIKEY Authentication Server rep- lication is not enabled.

Auditing

Auditing data should be written to databases at each site, and the data imported to the master auditing data- base at the administration site on a regular basis.

Reporting

Refer to the Reporting section of the IDENTIKEY Authentication Server Administrator Guide for more inform- ation.

Procedure 4: WAN Deployment Model setup

1. Install commercial database on each dedicated database server, and modify schema.

2. Set up replication between the databases.

3. Install IDENTIKEY Authentication Server on each primary server and the backup server, using the Advanced installation option.

4. Configure database load sharing on each IDENTIKEY Authentication Server.

5. Install a database on the audit server.

6. Set up auditing as required.

7. Configure reporting as required.

8. Make auditing data available for reporting – schedule merge of primary server's audit data with backup server auditing data using Maintenance Wizard application.

Note This chapter is ODBC storage specific.

2.

Deployment Models

2.6. Network Hardware Security Module Deployment Model

2.6. Network Hardware Security Module Deployment Model Image 6: Network HSM deployment model The Network HSM

Image 6: Network HSM deployment model

The Network HSM (Hardware Security Module) deployment model incorporates a Network HSM module. The HSM module performs EMV- CAP authentication and transaction validation related cryptographic processing. HSM requests are processed over the network from each individual IDENTIKEY Authentication Server.

Performance

Higher performance is achieved with the use of the third-party load balancer directing authentication requests to two primary IDENTIKEY Authentication Servers. Database load sharing to dedicated database servers is con- figured in each IDENTIKEY Authentication Server. A dedicated audit database is used for auditing and report- ing. Administration is performed via the backup IDENTIKEY Authentication Server, cutting down pressure on the primary servers. The Network HSM may serve as a performance limiting factor during high traffic periods, depending on the number of servers, the number of HSMs and speed of the network.

2.

Deployment Models

Availability

Availability of the system is maximised by allowing the third-party load balancer to handle load balancing and failover/failback between primary IDENTIKEY Authentication Servers. Additionally, each primary IDENTIKEY Authentication Server is configured to failover to a backup IDENTIKEY Authentication Server.

A backup database server is in use, and each IDENTIKEY Authentication Server is configured to connect to it automatically if the primary database server is not available.

IDENTIKEY Authentication Servers

Two primary IDENTIKEY Authentication Servers, two backup IDENTIKEY Authentication Servers, one dedicated administration, auditing and reporting IDENTIKEY Authentication Server.

Data is stored on dedicated database servers.

Administration

All administrative operations are performed on the administration server.

Long-running operations taking quite some time can be performed with no direct impact on the authen- tication server performance handling authentication requests (these administrative operations will introduce only a replication impact on the commercial database servers)

Administration scenario could be disabled on both primary servers and backup servers to exclude admin- istrative load. This is done via the Administration Web Interface.

Replication

Commercial replication enabled between database servers. IDENTIKEY Authentication Server replication dis- abled.

Auditing

Auditing data should be written to databases at each site, and the data imported to the master auditing data- base at the administration site on a regular basis.

Reporting

Refer to the Reporting section of the IDENTIKEY Authentication Server Administrator Guide for more inform- ation.

Procedure 5: Network HSM Deployment Model setup

1. Install commercial database on each dedicated database server, and modify schema.

2. Set up replication between the databases.

3. Install and configure HSM.

4. Install IDENTIKEY Authentication Server on each primary and backup server, using the Advanced install- ation option.

5. Configure database load sharing on each IDENTIKEY Authentication Server.

2.

Deployment Models

6. Install a database on the audit server.

7. Set up auditing as required.

8. Configure reporting as required.

9. Make auditing data available for reporting – schedule merge of primary server's audit data with backup server auditing data using Maintenance Wizard application.

Note This chapter is ODBC storage specific.

2.7. Internal Hardware Security Module Deployment Model

2.7. Internal Hardware Security Module Deployment Model Image 7: Internal Hardware Security Module deployment model

Image 7: Internal Hardware Security Module deployment model

The Internal HSM (Hardware Security Module) deployment model incorporates an Internal HSM module in each IDENTIKEY Authentication Server. The HSM module performs EMV-CAP authentication and transaction validation related cryptographic processing. HSM requests are performed on the IDENTIKEY Authentication Server which ini- tiates the request.

2.

Deployment Models

Performance

Higher performance is achieved with the use of the third-party load balancer directing authentication requests to two primary IDENTIKEY Authentication Server. Database load sharing to dedicated database servers is con- figured in each IDENTIKEY Authentication Server. A dedicated audit database is used for auditing and report- ing. Administration is performed via the backup IDENTIKEY Authentication Server, cutting down pressure on the primary servers.

Internal HSM modules may have an impact on performance, depending on the number and performance of your HSMs. Internal HSMs are less likely to impact performance than external HSMs.

Availability

Availability of the system is maximised by allowing the third-party load balancer to handle load balancing and failover/failback between primary IDENTIKEY Authentication Servers. Additionally, each primary IDENTIKEY Authentication Server is configured to failover to a backup IDENTIKEY Authentication Server.

A backup database server is in use, and each IDENTIKEY Authentication Server is configured to connect to it automatically if the primary database server is not available.

IDENTIKEY Authentication Servers

Two primary IDENTIKEY Authentication Servers, two backup IDENTIKEY Authentication Servers, one dedicated administration, auditing and reporting IDENTIKEY Authentication Server.

Data is stored on dedicated database servers.

Administration

All administrative operations are performed on the administration server.

Long-running operations taking quite some time can be performed with no direct impact on the authen- tication server performance handling authentication requests (these administrative operations will introduce only a replication impact on the commercial database servers)

Administration scenario could be disabled on both primary servers and backup servers to exclude admin- istrative load. This is done via the Administration Web Interface.

Replication

Commercial replication enabled between database servers. IDENTIKEY Authentication Server replication dis- abled.

Auditing

Auditing data should be written to databases at each site, and the data imported to the master auditing data- base at the administration site on a regular basis.

2.

Deployment Models

Reporting

Refer to the Reporting section of the IDENTIKEY Authentication Server Administrator Guide for more inform- ation.

Procedure 6: Internal HSM Deployment Model setup

1. Install commercial database on each dedicated database server, and modify schema.

2. Set up replication between the databases.

3. Install and configure HSM.

4. Install IDENTIKEY Authentication Server on each primary and backup server, using the Advanced install- ation option.

5. Configure database load sharing on each IDENTIKEY Authentication Server.

6. Install a database on the audit server.

7. Set up auditing as required.

8. Configure reporting as required.

9. Make auditing data available for reporting – schedule merge of primary server's audit data with backup server auditing data using Maintenance Wizard application.

Note This chapter is ODBC storage specific.

3.

Deployment Considerations

3.

Deployment Considerations

When deciding on a deployment model, the primary considerations are as follows:

1. Data replication: Will data replication be performed by IDENTIKEY Authentication Server, or a custom data- base replication program? Database replication may provide better performance than replication via IDENTIKEY Authentication Server, but may cost extra

2. Back-end authentication : Back-end server performance is largely dependent on the back-end used.

3. Load Balancing: Refer to 3.1. Load Balancing.

3.1. Load Balancing

Load balancing is a technique to spread client requests between two or more hardware servers to get optimal request throughput.

A load balancer can be either:

n

A software product to be installed on standard server hardware, or

n

A solution appliance with pre-installed software, configurable via a web interface (e.g. Barracuda Load Balancer).

Using multiple servers with load balancing, instead of a single server, can also increase reliability through redund- ancy.

load balancer typically exposes one virtual IP address and abstracts the IP addresses of each of its supporting servers. Each load balanced service is assigned a specific port on the load balancer.

A

A

loadbalancer/failover device needs to make an authentication request to the IDENTIKEY Authentication Server it

is

trying to reach to determine if that IDENTIKEY Authentication Server is still operational. To enable this check, and

to prevent this mechanism from interfering with reporting figures the following actions must be taken:

n

Create a dummy domain

n

Create a component which uses a policy which will accept password only authentications for the dummy domain

n

Update the policy so that the client component will only accept Users from the dummy domain.

n

Create a dummy User in the dummy domain

n

The User is created with password authentication

n

The User does NOT have admin privileges

n

The User is in a separate domain so the keep-alive authentications cannot contaminate normal authentication figures for reporting purposes.

n

Create a static password for the dummy User

n

Perform a SOAP authentication request from the load balancer with this User and password

If the IDENTIKEY Authentication Server the load balancer is trying to access is still enabled it will send a response.

3.

Deployment Considerations

Methods

Two setups exist for SSL communication between an Application and IDENTIKEY Authentication Server via a load-balancer:

n

SSL bridging (refer to 3.1.2. SSL Bridging)

n

SSL tunneling (refer to 3.1.1. SSL Tunneling )

Scheduling

Most load balancers support a variety of scheduling algorithms to distribute the client requests.

Common scheduling algorithms are:

n

Random: each incoming client request is forwarded to a random back-end server.

n

Round robin: incoming client requests are equally distributed over the different back-end servers. The load balancer determines the next server to send the request to by retrieving the next server entry in the list of available back-end servers.

n

Least connection: the load balancer forwards an incoming request to the server with the least number of active connections at that time.

Monitoring Frequency

Load balancers regularly monitor the health of each server. A load balancer automatically removes an offline or otherwise malfunctioning server from rotation, thereby preventing any authentication requests from reach- ing that server.

Carefully consider the frequency at which the load balancer should check each server. While a higher fre- quency of health checks ensures more updated information on server health, it also proportionally impacts the performance of IDENTIKEY Authentication Server.

Persistence

An important issue when operating a load-balanced service is how to handle information that must be kept across the multiple requests in a user's session.

If this information is stored locally on one back end server, then subsequent requests going to different back end servers would not be able to find it. This might be cached information that can be recomputed, in which case load-balancing a request to a different back end server just introduces a performance issue.

One solution to the session data issue is to send all requests in a user session consistently to the same back end server. This is known as "persistence" or "stickiness". A large downside to this technique is its lack of automatic failover: if a backend server goes down, its pre-session information becomes inaccessible, and sessions depending on it are lost.

The persistence could be performed based on the following information in the client request:

n

Client IP

n

HTTP Cookie

3.

Deployment Considerations

High-availability

Each load balancer should be deployed together with a backup load-balancer (mode primary-backup) to ensure high-availability (no single point of failure).

3.1.1. SSL Tunneling

(no single point of failure). 3.1.1. SSL Tunneling Image 8: SSL Tunneling (load balancing method) With

Image 8: SSL Tunneling (load balancing method)

With this load balancing method, SSL tunnels are created between the client and the IDENTIKEY Authentication Server.

Advantages

No data introspection possible by load-balancer.

Disadvantages

Not supported by all load balancers.

Persistence

Only persistence via client IP address is supported.

SSL certificates

This setup requires one commercial wildcard SSL certificate for the different client IDENTIKEY Authentication Server tunnels, to be installed on each of the back-end IDENTIKEY Authentication Servers.

3.

Deployment Considerations

3.1.2. SSL Bridging

With this load balancing method, the load balancer acts as end-point or terminator of all connections:

n

SSL tunnel between the client and the load-balancer (SSL tunnel 1 in the following diagram).

n

Tunnels between load-balancer and each of the back-end IDENTIKEY Authentication Servers (e.g. SSL tun- nel 2 in the following diagram).

Servers (e.g. SSL tun- nel 2 in the following diagram). Image 9: SSL Bridging (load balancing

Image 9: SSL Bridging (load balancing method)

Advantages

Since the load balancer acts as SSL tunnel end-point, the load-balancer can introspect the client request con- tents and easily handle persistent sessions.

Disadvantages

The load-balancer can introspect all sensitive information communicated by the client as it will at a some point in time be available in the clear on the load balancer. This security risk should be evaluated when this setup is considered.

Persistence

Following persistence mechanisms are supported:

n

Client IP address

n

HTTP cookie

3.

Deployment Considerations

SSL certificates

This setup requires following SSL certificates:

n

One commercial SSL certificate for the client-loadbalancer tunnel, to be installed on the load balancer.

n

Commercial or self-signed certificates for the individual back-end IDENTIKEY Authentication Servers. In case self-signed certificates are used, the certificates should be imported into the load-balancer to estab- lish trust with the back-end servers.

3.2. Rolling Upgrades

A rolling upgrade involves upgrading multiple IDENTIKEY Authentication Server instances while keeping the authen- tication service alive. Environments that require a rolling upgrade typically support high-availability services, where the authentication service absolutely cannot be taken offline.

An environment that requires a rolling upgrade typically has the following characteristics:

n

There are multiple instances of IDENTIKEY Authentication Server running on multiple servers.

n

All IDENTIKEY Authentication Server instances either use the same database as their data store, or each one instance has its own data store.

n

The IDENTIKEY Authentication Server upgrades involved will require a database schema update.

n

User load distribution between all IDENTIKEY Authentication Server instances is managed by a third-party application.

Note Rolling upgrades are only supported for deployments where each IDENTIKEY Authentication Server instance uses an ODBC data store.

Before proceeding with a rolling upgrade, you must first address the different usability and load management issues involved. For more information, refer to the IDENTIKEY Authentication Server Administrator Guide, Section "Rolling Upgrades".

3.3. Domain Considerations for ODBC Deployments

For ODBC deployments, IDENTIKEY Authentication Server uses the concept of a Master Domain. This domain has special significance in two ways:

1. It is used as the default domain, when no domain is specified.

2. Only administrators in the Master Domain may be assigned the privilege to view data from all domains. Administrators in other domains can view data in their own domain only.

The default name for the Master Domain is master. If you prefer, you can specify another name when you add the database schema. If the schema has already been added, you can change the Master Domain name during an advanced installation.

3.

Deployment Considerations

Note In the basic installation, the default name master is used. To change it, use the Administration Web Interface.

Only Administrators in the Master Domain may be assigned the privilege to view data from all domains. Admin- istrators in other domains will only ever be able to view data in their own domain.

When IDENTIKEY Authentication Server uses an ODBC data store, you can use domains to create organizational structures (otherwise it utilises the Active Directory organizational structure). Domains can be used to divide admin- istration between specific organizational divisions (for example, where some administrators should only have access to a single group of users). These domains may mirror actual domains in the corporate network.

3.3.1. Domains and Organizational Units

Domains and Organizational Units are included in the ODBC database in a way that mirrors the data structure used by Active Directory.

Organizational Units are designed to hold User accounts and DIGIPASS records. They allow grouping of Users according to department, job function, or other criteria. They also allow DIGIPASS to be allocated for Auto-Assign- ment to single or multiple groups of Users. Both Domains and Organizational Units can be used to limit admin- istrators to a group of Users and/or DIGIPASS.

limit admin- istrators to a group of Users and/or DIGIPASS. Image 10: Domains and Organizational Units

Image 10: Domains and Organizational Units

For more information, refer to the Domains and Organizational Units section of the IDENTIKEY Authentication Server Administrator Guide.

4.

Active Directory Deployment Considerations

4.

Active Directory Deployment Considerations

This chapter discusses issues to be considered in the context of IDENTIKEY Authentication Server Active Directory deployment.

4.1. Active Directory Permissions

When IDENTIKEY Authentication Server is installed onto a Domain Controller, the VASCO IDENTIKEY Authentication Server service runs under the Local System account rather than as a named user account. IDENTIKEY Authentic- ation Server connects to Active Directory as the computer account, not a user account. Therefore the permissions used by IDENTIKEY Authentication Server within Active Directory are the permissions of the computer account.

This means that the VASCO IDENTIKEY Authentication Server service (along with any other service running as Local System on the Domain Controller) has all possible permissions to that domain. Therefore, when IDENTIKEY Authentication Server is installed onto a Domain Controller, no further permission configuration is required.

Note For ANY group that uses Back-end authentication via LDAP and Active Directory, the permission List contents must be granted in the Active Directory Users and Computers Extension.

4.2. Active Directory Replication Issues

Active Directory replication is not instantaneous. Intra-site replication is usually quite fast but changes on one Domain Controller may still take several minutes to be replicated to other Domain Controllers. Inter-site replication may be quite slow – an hour or more between replications is common.

Replication occurs when more than one Domain Controller exists in a domain.

4.2.1. Old Data Used After Attribute Modified

The time period between replications becomes a problem where information is changed on one Domain Controller (for example, a DIGIPASS User's Server PIN is reset), but old information is used on another Domain Controller before the changed information has been replicated to it.

The following scenarios illustrate this:

Single IDENTIKEY Authentication Server using more than one Domain Controller

A single IDENTIKEY Authentication Server may make a change to a record, have to switch to another Domain Controller, and read the same record – where the change has not yet been applied.

4.

Active Directory Deployment Considerations

Example A User logs in with an OTP, and the IDENTIKEY Authentication Server connects to DC-01 to retrieve and update the DIGIPASS data. The connection to the DC-01 fails soon after login, before replication has occurred. The User needs to log in again, and the IDENTIKEY Authentication Server connects to DC-02 this time. The User can log in using the same OTP as the last login – the login should fail (OTP replay) but instead succeeds, because DC-02 does not yet know that the OTP has been previously used. The following timeline illustrates this:

Time

DC-01

DC-02

8:32

Replication occurs

8:34

User logs in with OTP 10457920. IDENTIKEY Authentication Server records the use of the OTP in the DIGIPASS record.

 

8:35

Connection to DC-01 is broken, and IDENTIKEY Authentication Server switches to DC-02.

 

8:35

 

User retries login using same OTP 10457920. The login succeeds where it should have failed (OTP replay). The IDENTIKEY Authentication Server records the use of the OTP in the DIGIPASS record.

8:37

Replication occurs. DIGIPASS record changes are replicated between DC-01 and DC-02.

Administrator and IDENTIKEY Authentication Server using different Domain Controllers

The administrator may not be connected to the same Domain Controller (via the Administration Interfaces) as the IDENTIKEY Authentication Server.

Example An administrator changes a User's Server PIN through the Active Directory Users and Computers Extension extension, which is connected to DC-01. The IDENTIKEY Authentication Server connects to DC-03. The User attempts a login using the new PIN, which fails because DC-03 is not yet aware of the Server PIN change. The following timeline illustrates this:

Time

DC-01

DC-03

9:02

Replication occurs

9:03

Administrator changes a User's Server PIN from 1234 to 9876.

 

9:04

 

User attempts to log in using new PIN (9876) and the login fails.

4.

Active Directory Deployment Considerations

Time

DC-01

DC-03

9:05

DIGIPASS record changes are replicated between DC-01 and DC-03.

Multiple IDENTIKEY Authentication Server instances using different Domain Controllers

Multiple IDENTIKEY Authentication Server may connect to different Domain Controllers in a domain or site.

Example A User changes their own PIN during a login through one IDENTIKEY Authentication Server which connects to DC-01. The server on which the IDENTIKEY Authentication Server is installed becomes unavailable, and the User attempts another login via the IDENTIKEY Authentication Server on a backup server, which connects to DC-02. The login fails because DC-02 is not yet aware of the change of Server PIN.

Time

DC-01

DC-02

11:54

Replication occurs

11:55

User changes his Server PIN from 1234 to 9876 during login. IDENTIKEY Authentication Server records the PIN change in the DIGIPASS record.

 

11:57

 

User attempts to log in using new PIN

(9876)

and the

login

fails.

11:59

Replication occurs. DIGIPASS record changes are replicated between DC-01 and DC-02.

Two Administrators Modifying the Same Attribute

Two administrators attempt to modify the same attribute on a single User account or DIGIPASS record within the same replication interval. The later modification will overwrite the earlier when replication occurs.

4.2.2. Old Data Used Overwrites New Data

The issues presented in 4.2.1. Old Data Used After Attribute Modified are exacerbated when the old information used on the second Domain Controller is updated based on old information. As the updated record on the second Domain Controller now has a later modification date, the end result is that the changed information on the first Domain Controller is overwritten incorrectly.

4.

Active Directory Deployment Considerations

Example An administrator connects to DC-01 and sets a User's PIN from 1234 to 9876 . The User logs in through IDENTIKEY Authentication Server, which connects to DC-02. The User enters the new Server PIN and his one-time password. However, the PIN set on DC-01 has not yet been replicated to DC-02, so because the PIN entered does not match the old PIN still recorded in the DIGIPASS record on DC-02, the login fails.

Because the Policy setting of Identification Threshold is in use, his login failure is written back to the DIGIPASS record. When replication occurs, the DIGIPASS record on DC-02 has the latest modification date – and is copied to DC-01, wiping out the original PIN setting made by the administrator. Both DC-01 and DC-02 now consider 1234 to be the correct Server PIN for the DIGIPASS. Refer to the following timeline:

Time

DC-01

DC-02

10:45

Replication occurs

10:46

Administrator changes Users's PIN from 9876 to

 

1234.

10:48

 

User login (with new PIN of 1234) fails. IDENTIKEY Authentication Server writes failure information to DIGIPASS record.

10:50

Replication occurs.

Active Directory finds last instance of the DIGIPASS blob having been modified. Active Dir- ectory overwrites DC-01 DIGIPASS record with DC-02 DIGIPASS record.

The problem shown in the aforementioned example may also occur in a Force PIN Change set by an administrator.

4.2.3. Mitigating Active Directory Replication Issues via DIGIPASS Cache

The DIGIPASS cache collects DIGIPASS records as they are modified, and keeps them in memory for a certain length of time. A newer entry from the cache is always used in preference to an older record from Active Directory. The cache age should be a little longer than the typical replication interval. The default is 10 minutes (600 seconds).

This option will help in problems caused by a single IDENTIKEY Authentication Server instance accessing more than one Domain Controller in a domain (refer to 4.2.1. Old Data Used After Attribute Modified for an example). This will also assist in problems caused by having multiple Authentication Servers accessing more than one Domain Con- troller in a domain, if IDENTIKEY Authentication Server replication is enabled between the servers.

However, this will not affect the scenario where an Administration Interface is connected to a Domain Controller dif- ferent from that used by IDENTIKEY Authentication Server.

If you calculate that your typical replication interval will be more than ten minutes, the cache age may be increased by modifying the Blob-Cache Max-Age setting in the configuration file (i.e. identikeyconfig.xml):

4.

Active Directory Deployment Considerations

<Blob-Cache>

<Max-Age type="unsigned" data="600"/>

<Max-Size type="unsigned" data="0"/>

<Clean-Threshold type="unsigned" data="10"/>

<Min-Clean-Interval type="unsigned" data="60"/>

</Blob-Cache>

The configuration file identikeyconfig.xml is located in:

/etc/vasco/ias/ (Linux)

<install_dir>\bin\ (Windows)

where <install_ dir> is the installation directory of IDENTIKEY Authentication Server (typically C:\Program Files\VASCO\IDENTIKEY Authentication Server)

A large cache may slow down processing slightly for the IDENTIKEY Authentication Server, so monitor performance to check the impact caused after modifying the cache age.

Warning If the IDENTIKEY Authentication Server is installed on a Member Server, this server must be closely time-syn- chronized with the Domain Controller(s). If the server is not time-synchronized, the Policy may select an older record when comparing records in the DIGIPASS cache with those on the Domain Controller.

If the IDENTIKEY Authentication Server is installed on a Domain Controller, time-synchronization is assumed.

4.3. IDENTIKEY Authentication Server and Multiple Domains

When using the IDENTIKEY Authentication Server with multiple domains, extra steps must be followed to ensure that both the IDENTIKEY Authentication Server and administrators have the required permissions for accessing required data. The main issues are:

n

The DIGIPASS Configuration Container is only in one Domain. All IDENTIKEY Authentication Server instances need read access to this container, even when they are in a different Domain. Cross-Domain access for administrators is a less likely requirement, however.

n

If an instance of IDENTIKEY Authentication Server handles users and DIGIPASS in more than one Domain, that instance needs to be granted the necessary permissions in all the necessary Domains.

The following instructions discuss cross-Domain permissions using a combination of Domain Local and Domain Global groups. It is also possible to use Universal groups in a native mode Domain, but this is not covered in the fol- lowing subsections.

Three possible scenarios for multiple domain setup are outlined in the following subsections:

4.

Active Directory Deployment Considerations

4.3.1. Scenario 1 – Each IDENTIKEY Authentication Server Handles One Domain

Each IDENTIKEY Authentication Server handles only the domain in which it is a member.

Install the IDENTIKEY Authentication Server in each domain (the result will be at least as many IDENTIKEY Authentic- ation Server as domains). Then, give each IDENTIKEY Authentication Server access to the DIGIPASS Configuration Domain. The following instructions illustrate how to do this.

Domain Global Group(s)

For each domain (apart from the DIGIPASS Configuration Domain):

1. Create a Domain Global group.

2. Add the IDENTIKEY Authentication Server(s) to the Domain Global group. Check which machines are in the RAS and IAS Servers group for which servers to add.

Domain Local group

In the DIGIPASS Configuration Domain:

1. Create or use an existing Domain Local group.

2. Give the Domain Local group full Read access to the DIGIPASS Configuration Container.

3. Add the Domain Global Group from each other domain to the Domain Local group.

4.3.2. Scenario 2 – One IDENTIKEY Authentication Server instance Handles All Domains

IDENTIKEY Authentication Servers in one domain handle all domains. The DIGIPASS Configuration Container should be located in the domain to which the IDENTIKEY Authentication Servers belong.

Give the necessary access to User and DIGIPASS data:

Domain Global group

In the RADIUS server Domain:

1. Create a Domain Global group.

2. Add the IDENTIKEY Authentication Servers to the Domain Global group.

Domain Local groups

For each other Domain:

1. Create a Domain Local group.

2. Give the Domain Local group the required permissions. To do so, run the following command:

dpadadmin.exe setupaccess -group "<domain_local_group>" -c

4.

Active Directory Deployment Considerations

where <domain_local_group> is the name of the Domain Local group created in the previous step. This command will add the member server to the specified Domain Local group, and grant all the additional required permissions. For more information on the setupaccess command, refer to 4.4. Assigning DIGIPASS Permissions to a Group.

The changes by this command will only take effect after a restart.

3. Add the Domain Global group from the IDENTIKEY Authentication Server Domain to the Domain Local group.

4.3.3. Scenario 3 - Combination

This scenario represents more complex setups, where a combination of steps from Scenarios 1 and 2 will be required. Use the steps given in the first two scenarios as a guide for what you will need to do for the combination scenario.

Note If IDENTIKEY Authentication Server is installed on a child domain, and the parent domain is specified as a con- figuration domain, the child domain administrator that is being used to install IDENTIKEY Authentication Server needs to be added to the IDENTIKEY Authentication Server global group created in the child domain. This is so that the administrator has permission to manipulate IDENTIKEY Authentication Server items in the parent domain. After the permissions are assigned the child domain administrator will have to logout and login again for the new permissions to take effect

4.4. Assigning DIGIPASS Permissions to a Group

To assign DIGIPASS-specific permissions to a Windows group, you can use the dpadadmin setupaccess command.

The dpadadmin setupaccess command assigns the following permissions:

n

Full read access to everything in the domain

n

Full control over vasco-DPToken objects

n

Full control over vasco-DPApplication objects

n

Full write access to vasco-UserExt auxiliary objects

Procedure 7: Assigning DIGIPASS Permissions to a Group

1. Log into the target domain's machine as a domain administrator in that domain.

2. Copy dpadadmin.exe onto the machine.

You can retrieve dpadadmin.exe from the installation folder (by default C:\Program Files\VASCO\IDENTIKEY Authentication Server) or from the following folder on the product installation CD:

4.

Active Directory Deployment Considerations

\Software\Windows\Utilities\dpadadmin

3. Open a Command Prompt window and navigate to the location where you copied the dpadadmin.exe.

4. Run the following command:

dpadadmin.exe setupaccess -group <group_name> [-domain <FQDN>] [-q] [-c]

where:

n

<FQDN> is the fully-qualified domain name of the domain.

n

<group_name> is the target group.

The progress and success/failure of the command will be displayed in the Command Prompt window.

Note The changes by this command will only take effect after a restart.

5.

Audit and Report Performance

5.

Audit and Report Performance

Although IDENTIKEY Authentication Server offers a variety of audit methods, for reporting it is required to audit to a database (ODBC Database audit method). This will be the case by default if you install the PostgreSQL database shipped with IDENTIKEY Authentication Server. With other audit methods, e.g. auditing to a text file, you will not be able to use the IDENTIKEY Authentication Server reporting features.

Auditing to ODBC database requires the following tables:

n

vdsAuditMsg: Basic audit message, including mandatory audit message fields

The vdsAuditMsg table will contain one record per audit message generated, with additional information held in the vdsAuditMsgField table.

n

vdsAuditMsgField: Contains extra (non-mandatory) audit message fields which may be included in an audit message

The vdsAuditMsgField table may contain several records for a single audit message.

To enhance authentication and audit/report performance, you can set indexing on searchable fields as needed. Depending on your deployment model and how you intend to use the auditing/reporting features, you can choose from the following indexing levels:

n

0 – Do not apply any indexing to searchable fields.

n

1 – Apply standard reporting indexing to searchable fields.

n

2 – Apply full reporting indexing to searchable fields .

For information on setting indexing levels refer to Appendix.1. Adding Indexing for Report Performance . For a detailed description of the indexing levels refer to the IDENTIKEY Authentication Server Administrator Reference.

Following the indexing level recommendations in this chapter will optimize authentication and audit/report per- formance if you intend to work with the User Dashboard , view recent user and DIGIPASS activity, and use IDENTIKEY Authentication Server reporting.

5.1. Recommendations for Basic and Advanced Deployment Models

With the basic and advanced deployment models (see 2.1. Basic Deployment Model and 2.2. Advanced Deploy- ment Model), it is recommended that you set the level of indexing as follows:

n

vdsAuditMsg: Indexing level 1

n

vdsAuditMsgField: Indexing level 0

For information on setting indexing levels refer to Appendix.1. Adding Indexing for Report Performance.

Note As from IDENTIKEY Authentication Server 3.8, these are the default indexing levels for new installations.

5.

Audit and Report Performance

5.2. Recommendations for High Availability Deployment Models

The recommendations in this section apply to the following deployment models:

n

High availability deployment model (see 2.3. High Availability Deployment Model)

n

Maximum availability deployment model (see 2.4. Maximum Availability Deployment Model)

n

WAN deployment model (see 2.5. WAN Deployment Model)

n

Network Hardware Security Module deployment model (see 2.6. Network Hardware Security Module Deployment Model)

n

Internal Hardware Security Module deployment model (see 2.7. Internal Hardware Security Module Deploy- ment Model)

With these deployment models, it is recommended that you set the level of indexing as follows:

For dedicated administration and reporting servers:

n

vdsAuditMsg: Indexing level 2

n

vdsAuditMsgField: Indexing level 0

For dedicated authentication servers:

n

vdsAuditMsg: Indexing level 0

n

vdsAuditMsgField: Indexing level 0

For information on setting indexing levels refer to Appendix.1. Adding Indexing for Report Performance.

5.3. Additional Audit and Report Considerations

When working with IDENTIKEY Authentication Server auditing and reporting, you should also consider the fol- lowing:

n

If you do not wish to use the User Dashboard or the reporting features, or view recent user and DIGIPASS activity, it is recommended that you set the indexing level for the vdsAuditMsg table to 0, to further enhance authentication performance.

n

Changing the indexing level for the vdsAuditMsgField table is not required for IDENTIKEY Authentication Server auditing and reporting to function properly.

6.

Performance Baselines

6.

Performance Baselines

This chapter discusses the baselines used to test the performance of IDENTIKEY Authentication Server 3.10.

6.1. Performance Test Setup

IDENTIKEY Authentication Server was installed, configured and run on an application server in the configurations given below. Performance data was gathered using the following methods:

n

A DIGIPASS record import was performed. The time taken for the import was recorded.

n

A user record import was performed and DIGIPASS were automatically assigned. The time taken for the import was recorded.

n

Test timing:

n

Authentication performance tests were run for twenty minutes with the last fifteen minutes recor- ded for statistics.The tests were repeated for each protocol used.

n

Node scaling tests run for ten minutes with five minutes of data gathering.

n

Authentication while reporting tests were run for thirty minutes with fifteen minutes of data gath- ering. The report generation was started after fifteen minutes.

n

The top and average number of authentications per second was recorded.

Note Only authentications/second were recorded. Other transactions – such as administration, auditing, and reporting – were not counted.

Application Server - Hardware

n

Intel Xeon E5630

n

12GB RAM

n

146GB Hard Disk (system disk)

n

HP Smart array P410i/256 MB controller

n

Network

n

2 * HP NC382i Dual Port Multifunction Gigabit Svr Adapter

n

HP NC360TOCUe DP Gbit Adapter

Database Server – Hardware

n

Intel Xeon E5630

n

12GB RAM

n

HP Smart array P410i/256 MB controller

n

HP 146GB Hard Disk

n

Network

n

2 * HP NC382i Dual Port Multifunction Gigabit Svr Adapter

n

HP NC360TOCUe DP Gbit Adapter

Virtual SAN Server

This is used for the Oracle clusters in the Oracle testing, and for MSSQL Mirroring.

6.

Performance Baselines

n

Quad Core Intel Zeon E5430

n

8GB RAM

n

6 *Hewlett-Packard 146GB 10K SAS 2.5 HP HDD

n

HP Smart array P410i/256 MB controller

n

Network

n

Embedded dual NC373i Multi-function Gigabit Network Adaptors

n

HP NC 364T PCIe 4 Port Gbit Adapter

n

HP NC360T PCIe 2port Gbit Adapter

n

Operating System -FreeNAS9

6.

Performance Baselines

6. Performance Baselines Image 11: Relationship between IDENTIKEY Authentication Server, Database Servers, and SAN

Image 11: Relationship between IDENTIKEY Authentication Server, Database Servers, and SAN Server

6.2. Software Environments

The following table lists the different software environments used for the performance tests.

6.

Performance Baselines

Table 2: Software environments used for testing

 

Operating

User/DIGIPASSvolume

Database Con-

HSM?

Auditing

Server con-

Test

System

figuration

Destination

figuration

A

Windows

 

20

000

Embedded

N

Text file

Application only

Server

   

PostgreSQL

2008

R2 64

9.2

bit

B

Windows

2

000 000

MSSQL 2008

N

Database

Application, 1 x database

Server

   

2008

R2 64

 

bit

C

Red Hat

 

20

000

Embedded

N

Text file

Application,only

Linux 5.5

 

PostgreSQL

64

bit

8.3

D

Red Hat

200 000

Oracle Data- base 11g R2

N

Database

Application, 2 x database, SAN

Linux 5.5

64

bit

RAC

 

E

Red Hat

2

000 000

Oracle Data- base 11g R2

N

Database

Application, 2 x database, SAN

Linux 5.5

 

64

bit

RAC

 

F

Red Hat

2

000 000

Oracle Data- base 11g R2

Y

Database

Application, 2 x database, SAN

Linux 5.5

 

64

bit

RAC

 

Configuration

n

Communication Protocols:

 

n

SOAP over SSL

n

RADIUS (including PAP, CHAP, MSCHAP and MSCHAP2)

n

SEAL over SSL, with DIGIPASS Authentication for Windows Logon installed and enabled

n

Auditing to text file or to database, as specified in Auditing Destination above.

n

Reporting: No reporting, or from database.

Test Definition

n

DIGIPASS Record Import: Using DPX import tool.

n

User Import and Assign: Import using Tcl command line.

n

Authentication with no reporting: Report generation not running during test.

n

Authentication with reporting on authentication server: Report generation running on authentication server during test.

n

Authentication with dedicated reporting server: Report generation running on dedicated reporting server during test.

n

Node Scaling: Authentication using 1, 2, or 3 IDENTIKEY Authentication Server application servers against the database.

n

Performance Monitoring Impact: Performance Monitoring to .csv file activated for this test.

6.

Performance Baselines

6.3. Results

The following tables show the results for different test criteria. Table 3: Import records results

Action

 

A

B

C

 

D

E

 

F

 

DIGIPASS record import

 

4m

16h

4m

2h

22h

25h

16s

29m

27s

10m

01m

03m

 

06s

43S

10s

18s

User import and assign

 

8m

32h

8m

8h

45h

52h

51s

7m

20s

45m

35m

26m

 

45s

21s

52s

Table 4: Authentication results, in auths/sec (no reporting)

 

Configuration

 

A

 

B

 

C

 

D

 

E

 

F

Avg

Max

Avg

 

Max

Avg

Max

Avg

Max

Avg

Max

Avg

Max

Authentication with no reporting (Auths/Sec)

 

SOAP/SSL

429

507

482

 

547/537

148

188

76

219

80

113/112

52

102

RADIUS/PAP

396

553

490

 

569/560

150

185

63

195

31

49/49

30

70

RADIUS/CHAP

n/a

n/a

n/a

 

n/a

80

131

n/a

n/a

32

58/53

n/a

n/a

RADIUS/MSCHAP

n/a

n/a

n/a

 

n/a

83

176

n/a

n/a

31

55/42

n/a

n/a

RADIUS/MSCHAP2

n/a

n/a

n/a

 

n/a

81

126

n/a

n/a

32

54/55

n/a

n/a

SEAL/SSL

361

514

401

 

339/420

77

143

154

181

78

106/116

62

113

Authentication with reporting on authentication server (Auths/Sec)

 

SOAP/SSL

343

495

185

 

219

155

241

71

104/101

123

147/121

n/a

n/a

Authentication with dedicated reporting server (Auths/Sec)

 

SOAP/SSL

n/a

n/a

538

 

575/575

n/a

n/a

n/a

n/a

80

107/112

   

Node Scaling (Auths/Sec)

 

1 server SOAP/SSL

n/a

n/a

364

 

574

n/a

n/a

n/a

n/a

65

133

n/a

n/a

2 servers SOAP/SSL

n/a

n/a

563

 

580/589

n/a

n/a

n/a

n/a

79

110/114

n/a

n/a

3 servers SOAP/SSL

n/a

n/a

630

 

569/539/538

n/a

n/a

n/a

n/a

84

104/96/91

n/a

n/a

Performance Monitoring Impact

 

SOAP/SSL

n/a

n/a

n/a

 

n/a

n/a

n/a

n/a

n/a

77

117/106

n/a

n/a

6.

Performance Baselines

6.4. Variations

Communication Protocol

The protocol to be used will depend primarily on your current network infrastructure. Results indicate that IDENTIKEY Authentication Server. performs better using SOAP when using a local database. When using RADIUS, all protocol types provide similar performance levels.

Auditing and Reporting

Auditing to database decreases performance – on multiple- IDENTIKEY Authentication Server systems, con- sider an IDENTIKEY Authentication Server dedicated to auditing and other administrative tasks, or using a sep- arate auditing database.

6.5. Recommendations

The following recommendations are made based on the testing performed:

n

If your database size is over 20,000 user accounts and DIGIPASS records, it is recommended to have bulk administration and report generation handled by a separate machine, either a backup server or a ded- icated server.

n

If your database size is around 20,000 user accounts and DIGIPASS records, consider a separate database server for the main data store and a separate database for auditing and reporting.

n

Consider using RAID-5 disk striping and faster disks if your sustained or peak transaction rate - authen- tications plus other requests, eg. administration and digital signatures - is above 50 authen- tications/second, unless the database and auditing are handled with fast, separate database servers.

APPENDIX

APPENDIX

The following sections contain supplementary information relevant to this book. For more detailed information on each topic, refer to 1.2. IDENTIKEY Authentication Server Documentation Suite for related documentation.

Appendix.1. Adding Indexing for Report Performance

The dpdbadmin addindex command adds indexing on searchable fields to enhance report performance. If this command is run against your database it will have a minor effect on authentication performance. Increasing the level of indexing will negatively affect authentication performance.

It may be necessary to go through an approval process in your company before performing this task. You may also need to have a database administrator perform the task for you.

Database Name

You will need the Data Source Name of the database (as registered with Windows or Linux as an ODBC Data Source). This DSN must be registered on the computer from which the command line utility will be run.

Database Administrator Account

In order to successfully modify the database structure, you will need the username and password of a data- base administrator account that is able to make changes to the database structure. You must pass these cre- dentials to the utility in the parameters of the command.

To add indexing for report performance, use the following command:

dpdbadmin addindex –u <dbusername> –p <dbpassword> -d <dsn> -level <lvl>

where:

n

<dbusername> is the user name of the database administrator account

n

<dbpassword> is the corresponding password of <dbusername>

n

<dsn> is the ODBC data source name

n

<lvl> refers to the level of indexing to apply; this should be 0, 1, or 2

For more information about dpdbadmin addindex, refer to the IDENTIKEY Authentication Server Admin- istrator Reference.