IDENTIKEY Authentication Server Deployment and Performance Guide

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
IDENTIKEY Authentication Server - Performance and Deployment Guide 3

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 of Contents
Table Index
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

Table of Contents
Illustration Index
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

Table of Contents
Procedure Index
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
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.1. 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.

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

2.2. 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.

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

2.3. High Availability Deployment Model
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.

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.

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.

8. Schedule making data available for reporting - merge of primary servers audit files with backup server
auditing information using the Maintenance Wizard.
Note
2.4. Maximum Availability Deployment Model
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.

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.

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.
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

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.
3. Install IDENTIKEY Authentication Server on each primary and backup server, using the Advanced install-
ation option.
server auditing data using Maintenance Wizard application.
Note

2.5. 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.

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.

All primary commercial database servers replicating with each other and with the backup database server.
Dedicated database server for auditing data.
Administration
only a replication impact on the commercial database servers).
Replication
Custom database replication used over the Virtual Private Network. IDENTIKEY Authentication Server rep-
lication is not enabled.
Auditing
Reporting
ation.
Procedure 4: WAN Deployment Model setup
1. Install commercial database on each dedicated database server, and modify schema.
3. Install IDENTIKEY Authentication Server on each primary server and the backup server, using the Advanced
installation option.
Note

2.6. Network Hardware Security Module Deployment Model
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
to two primary IDENTIKEY Authentication Servers. Database load sharing to dedicated database servers is con-
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.

Availability

Administration
Long-running operations taking quite some time can be performed with no direct impact on the authen-
Replication
abled.
Auditing
Reporting
ation.
Procedure 5: Network HSM Deployment Model setup
3. Install and configure HSM.
ation option.


Note
2.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.

Performance
to two primary IDENTIKEY Authentication Server. Database load sharing to dedicated database servers is con-
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

Administration
Long-running operations taking quite some time can be performed with no direct impact on the authen-
Replication
abled.
Auditing

Reporting
ation.
Procedure 6: Internal HSM Deployment Model setup
3. Install and configure HSM.
ation option.
Note

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.
A 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 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.

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

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
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.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).
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

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.

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.
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

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.

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: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.

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: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.

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: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):

<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.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

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:

\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

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.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:

For dedicated authentication servers:

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
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 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.

n Quad Core Intel Zeon E5430

n 8GB RAM
n 6 *Hewlett-Packard 146GB 10K SAS 2.5 HP HDD
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

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.

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

Server database
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- N Database Application, 2 x

Linux 5.5 base 11g R2 database, SAN
64 bit RAC
E Red Hat 2 000 000 Oracle Data- N Database Application, 2 x

64 bit RAC
F Red Hat 2 000 000 Oracle Data- Y Database Application, 2 x

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.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.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.

IDENTIKEY Authentication Server Deployment and Performance Guide

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

IDENTIKEY Authentication Server Deployment and Performance Guide

Hochgeladen von

Copyright:

Verfügbare Formate

IDENTIKEY Authentication Server

Performance and Deployment Guide

Date last modified: 6/27/2016

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.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.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

IDENTIKEY Authentication Server - Performance and Deployment Guide 3

6.1. Performance Test Setup 43

6.2. Software Environments 45

Appendix.1. Adding Indexing for Report Performance 49

IDENTIKEY Authentication Server - Performance and Deployment Guide 4

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

IDENTIKEY Authentication Server - Performance and Deployment Guide 5

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

IDENTIKEY Authentication Server - Performance and Deployment Guide 6

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

IDENTIKEY Authentication Server - Performance and Deployment Guide 7

1.1. Who should read this guide?

1.2. IDENTIKEY Authentication Server Documentation Suite

The following IDENTIKEY Authentication Server guides are available:

IDENTIKEY Authentication Server - Performance and Deployment Guide 8

n IDENTIKEY Authentication Server SDK Programmer's Guide: information on the IDENTIKEY Authentication

1.2.1. Further assistance

1.3. Factors Affecting IDENTIKEY Authentication Server Performance

IDENTIKEY Authentication Server - Performance and Deployment Guide 9

n Number of Users in the system

See the table below for a summary.