Identikey Server Performance and Deployment Guide 3.1

Identikey Server Performance and Deployment Guide 3.1

Disclaimer of Warranties and Limitations of Liabilities Disclaimer of Warranties and Limitations of Liabilities The Product is provided on an 'as is' basis, without any other warranties, or conditions, express or implied, including but not limited to warranties of merchantable quality, merchantability of fitness for a particular purpose, or those arising by law, statute, usage of trade or course of dealing. The entire risk as to the results and performance of the product is assumed by you. Neither we nor our dealers or suppliers shall have any liability to you or any other person or entity for any indirect, incidental, special or consequential damages whatsoever, including but not limited to loss of revenue or profit, lost or damaged data of other commercial or economic loss, even if we have been advised of the possibility of such damages or they are foreseeable; or for claims by a third party. Our maximum aggregate liability to you, and that of our dealers and suppliers shall not exceed the amount paid by you for the Product. The limitations in this section shall apply whether or not the alleged breach or default is a breach of a fundamental condition or term, or a fundamental breach. Some states/countries do not allow the exclusion or limitation or liability for consequential or incidental damages so the above limitation may not apply to you. Copyright Copyright 2009 VASCO Data Security, Inc., VASCO Data Security International GmbH. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of VASCO Data Security Inc. RADIUS Documentation Disclaimer The RADIUS documentation featured in this manual is focused on supplying required information pertaining to the RADIUS server and its operation in the Identikey Server environment. It is recommended that further information be gathered from your NAS/RAS vendor for information on the use of RADIUS. Trademarks VASCO, Vacman, IDENTIKEY, axs GUARD, DIGIPASS, and are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries. Document version: 1.1

Table of Contents Table of Contents 1 Introduction... 4 1.1 Scope... 4 1.2 Identikey Server Functionality... 4 1.3 Selecting a Deployment Model... 4 1.4 How Can We Get the Best Possible Performance from Identikey Server?... 5 2 Deployment Models... 6 2.1 Basic Deployment Model... 7 2.2 Advanced Deployment Model... 9 2.3 High-Availability Deployment Model... 11 2.4 Maximum-Availability Deployment... 14 2.5 WAN Deployment Model... 17 3 Deployment Considerations... 19 3.1 Data Replication... 19 3.2 Back-End Authentication... 19 3.3 Load balancing... 19 4 Performance Baselines... 23 4.1 Performance Setup... 23 4.2 Results... 24 4.3 Variations... 25 4.4 Recommendations... 25 4.5 Limitations... 25 Identikey Server Performance and Deployment Guide 3

Introduction 1 Introduction This guide contains information on deploying Identikey Server, and performance statistics detailing the performance of Identikey Server in different deployment models. 1.1 Scope Only Identikey Server installations using an ODBC database as their data store are covered in this guide Installations of Identikey Server using Active Directory as their data store are not covered, as performance differs widely depending on the Active Directory implementation in use. 1.2 Identikey Server Functionality An Identikey Server installation may be utilized for: Authentication Signature validation Auditing Co-ordinating distribution of Digipass (provisioning) Administration of data, configuration and authentication settings Reporting In larger systems, single Identikey Servers 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. See the Scenarios section of the Product Guide for more information. 1.3 Selecting a Deployment Model A number of options are available to scale Identikey Server to the level of operability, availability and performance required by your company. Below is a brief summary of the basic deployment models suggested. See the Deployment Models section for more detailed information. Basic This deployment model is useful for a low-traffic system, such as a small company's internal network on a single site. It may also be used to evaluate Identikey Server. Identikey Server Performance and Deployment Guide 4

Introduction Advanced The Advanced model is designed for a moderate-traffic system and supports faster disaster recovery. High Availability The High Availability model is an example of the setup for a higher-traffic system, with better performance and greater availability, achieved with load balancing and failover. Maximum Availability This model approximates a system where authentication may NOT fail under any circumstances. Load balancing is performed between two or more Identikey Servers, with dedicated backup Identikey Servers for each. Wide Area Network Multi-site deployment with intra-site replication. 1.4 How Can We Get the Best Possible Performance from Identikey Server? Some elements which will affect performance in Identikey Server are: Machine specifications Data store type, and location(s) Data replication method Load balancing and failover options Auditing method Authentication protocol Tracing enabled or disabled See the Performance Guidelines chapter of this guide for more information. Identikey Server Performance and Deployment Guide 5

2 Deployment Models Five basic deployment models are covered in this guide. The deployment model which will apply best to your situation depends on these basic factors: Number of Users in the system Amount of authentication traffic Number of sites needing authentication 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 per second Number of sites System availability required Standard < 50 < 50 1 Normal Advanced 50-20 000 < 50 1 Normal High Availability 100 50 000 > 50 1 High Maximum Availability < 200 000 > 100 1 Critical WAN 50 200 000 < 50 multiple High Identikey Server Performance and Deployment Guide 6

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 network or an evaluation of Identikey Server. Identikey Servers A single Identikey Server installation, which handlies authentication, auditing and administration tasks. It uses the embedded PostgreSQL database as its data store. Administration Administration done on 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 Auditing would typically be done to a text file, as this is the simplest option. Identikey Server Performance and Deployment Guide 7

Reporting Reporting should be configured to extract information from the auditing text file. See the Reporting section of the Administrator Reference for more information. 2.1.1 Deployment Steps Install Identikey Server on a machine, using the basic installation option. This will also install and set up a Tomcat web server, the Administration Web Interface, and an embedded PostgreSQL database. 2.1.2 Limitations No failover support or data replication included. Recovery time from any machine or data problems may be extensive. Identikey Server Performance and Deployment Guide 8

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 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 minimal effort, as replication will have kept the data up to date. Identikey Servers Two Identikey Server installations: 1 primary, dedicated to handling authentication requests 1 backup, available for authentication requests if required, used for administration Administration Administration link to backup server. Replication 2-way replication enabled on both Identikey Servers. See the Replication section of the Administrator Reference for more information. Auditing Two options: Auditing to text file on both servers Identikey Server Performance and Deployment Guide 9

Auditing to text file on primary server and auditing to database on backup server See the Auditing sections of the Product Guide and Administrator Reference for more information. Reporting Reporting should be configured via the reporting scenario options in the configuration utility or via the Administration Web Interface. Two basic options: input from auditing file (if auditing configured to file) input from local database (if auditing configured to database) 2.2.2 Deployment Steps 1. Install Identikey Server on primary machine. 2. Install Identikey Server on backup machine. 3. Install Administration Web Interface on backup server. 4. Configure 2-way replication on each Identikey Server. 5. Optional: disable administration scenario on primary server 6. Schedule making data available for reporting: 7. Merge primary server audit files with backup server auditing information using configuration wizard application (see the Making data available for reporting topic in the Reporting section of the Product Guide for more information). Identikey Server Performance and Deployment Guide 10

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 availability. Performance Higher performance is achieved with the use of load-balancing in client-side applications, between two primary Identikey Servers. Database load sharing to dedicated database servers is configured in each Identikey Server. A dedicated audit database is used for auditing and reporting. Administration is performed via the backup Identikey Server, cutting down pressure on the primary servers. Availability Availability of the system is increased by the configuration of failover and failback between Identikey Servers, and the use of a backup database server. Identikey Server Performance and Deployment Guide 11

Note Client side load-balancing and fail-over is built in into the client application in this type of deployment. Identikey Servers Two primary Identikey Servers and one backup Identikey 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 authentication 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. See the Scenarios section of the Administrator Reference for more information. Replication Custom database replication used. Identikey Server replication is not enabled. Auditing Auditing from primary Identikey Servers: auditing to text file, or auditing immediately to the audit database Auditing from backup Identikey Server: Reporting Dedicated auditing database used Reporting should be configured to collect input from the auditing database for increased report generation performance. This can be done via the reporting scenario in the Identikey Server Configuration GUI, or the Administration Web Interface. See the Scenarios section of the Administrator Reference for more information. 2.3.1 Deployment Steps 1. Install commercial database on each dedicated database server, and modify schema. 2. Set up replication between the databases. Identikey Server Performance and Deployment Guide 12

3. Install Identikey Server on each primary server and the backup server, using the Advanced installation option. 4. Configure database load sharing on each Identikey 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 configuration wizard application. Identikey Server Performance and Deployment Guide 13

2.4 Maximum-Availability Deployment 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 Servers. Database load sharing to dedicated database servers is configured in each Identikey Server. A dedicated audit database is used for auditing and reporting. Administration is performed via the backup Identikey Server, cutting down pressure on the primary servers. Identikey Server Performance and Deployment Guide 14

Availability Availability of the system is maximised by allowing the third-party load balancer to handle load balancing and failover/failback between primary Identikey Servers. Additionally, each primary Identikey Server is configured to failover to a backup Identikey Server. A backup database server is in use, and each Identikey Server is configured to connect to it automatically if the primary database server is not available. Identikey Servers Two primary Identikey Servers, two backup Identikey Servers, one dedicated administration, auditing and reporting Identikey Server. Data 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 authentication 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 administrative load. See the Scenarios section of the Administrator Reference for more information. Replication Commercial replication enabled between database servers. Identikey Server replication disabled. Auditing Auditing on primary and backup Identikey Servers: auditing to text file, or auditing immediately to the audit database Auditing to audit database on admin server Reporting Reporting with auditing input from database for increased report generation throughput Reporting to be configured via reporting scenario configuration utility (see administration reference guide; reporting scenario configuration) or via web administration. Identikey Server Performance and Deployment Guide 15

2.4.1 Deployment Steps 1. Install commercial database on each dedicated database server, and modify schema. 2. Set up replication between the databases. 3. Install Identikey Server on each primary and backup server, using the Advanced installation option. 4. Configure database load sharing on each Identikey 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 configuration wizard application. Identikey Server Performance and Deployment Guide 16

2.5 WAN Deployment Model Image 5: Wide Area Network Deployment Model The WAN deployment model illustrates an multi-site deployment of Identikey Server, with data regularly replicated between sites. Administration and reporting is handled in a single location. Other sites handle only authentication, validation and provisioning requests. Identikey Servers One primary/backup pair of Identikey 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 Server for authentication requests only. One administration site with a dedicated Identikey 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. Identikey Server Performance and Deployment Guide 17

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 authentication 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 administrative load. See the Scenarios section of the Administrator Reference for more information. Replication Custom database replication used over the Virtual Private Network. Identikey Server replication is not enabled. Auditing Auditing from primary Identikey Servers: auditing to text file, or auditing directly to the audit database Auditing from backup Identikey Server: Reporting Dedicated auditing database used Reporting should be configured to collect input from the auditing database for increased report generation performance. This can be done via the reporting scenario in the Identikey Server Configuration GUI, or the Administration Web Interface. See the Scenarios section of the Administrator Reference for more information. 2.5.2 Deployment Steps 1. Install commercial database on each dedicated database server, and modify schema. 2. Set up replication between the databases. 3. Install Identikey Server on each primary server and the backup server, using the Advanced installation option. 4. Configure database load sharing on each Identikey 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 configuration wizard application. Identikey Server Performance and Deployment Guide 18

Deployment Considerations 3 Deployment Considerations 3.1 Data Replication Will data replication be performed by Identikey Server, or a custom database replication program? Database replication may provide better performance than replication via Identikey Servers, but may cost extra. 3.2 Back-End Authentication Back-end server performance is largely dependent on the back end used. 3.3 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 a software product to be installed on standard server hardware or can be a solution (appliance with pre-installed software; configuration 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 redundancy. 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. Methods 2 setups exist for SSL communication between an Application and Identikey Server via a load-balancer: SSL bridging SSL tunneling Scheduling Most load balancers support a variety of scheduling algorithms to distribute the client requests. Common scheduling algorithms are: Random: each incoming client request is forwarded to a random back-end server. 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. Identikey Server Performance and Deployment Guide 19

Deployment Considerations Least connection: the load balancer forwards an incoming request to the server with the least number of active connections at that time. 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 loadbalancing 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: Client IP 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.3.2 SSL Bridging In this setup, the load balancer acts as end-point or terminator of all connections: SSL tunnel between the Identikey client and the load-balancer (SSL tunnel 1 in the diagram above). Tunnels between load-balancer and each of the back-end Identikey Servers (e.g. SSL tunnel 2 in the diagram above). Identikey Server Performance and Deployment Guide 20

Deployment Considerations Advantages Since the load balancer acts as SSL tunnel end-point, the load-balancer can introspect the client request contents and easily handle persistent sessions. Disadvantages The load-balancer can introspect all sensitive information communicated by the Identikey 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: Client IP address HTTP cookie SSL certificates This setup requires following SSL certificates: 1 commercial SSL certificate for the client-loadbalancer tunnel, to be installed on the load balancer. Commercial or self-signed certificates for the individual back-end Identikey servers. In case self-signed certificates are used, the certificates should be imported into the load-balancer to establish trust with the backend servers. 3.3.3 SSL Tunneling In this setup, SSL tunnels are created between the Identikey client and the Identikey Server. Advantages No data introspection possible by load-balancer. Disadvantages Not supported by all load balancers. Identikey Server Performance and Deployment Guide 21

Deployment Considerations Persistence Following persistence mechanisms are supported: Client IP address SSL certificates This setup requires following SSL certificate: 1 commercial wildcard SSL certificate for the different client-identikey server tunnels, to be installed on each of the back-end Identikey Servers. 3.3.3.2 IK3 Load balancing limitations There are a number of theoretical limitations on using load balancing for client requests communicated to Identikey Server 3.1: Authentication Following load-balancing limitations exist for the authentication API: 1-step CR: subsequent authentication request should be handled by the same Identikey server as the one generating the challenge. 2-step CR: second step of authentication request should be handled by the same Identikey server as the one generating the challenge. Provisioning No load balancing issues expected for provisioning. Administration Following load-balancing limitations exist for the administration API: Administrative sessions: all administration operations are session based. They require a prior administrative logon before they can be executed. Administrative sessions are tied to a specific Identikey Server and should therefore not be balanced between different Identikey Servers. Reporting Following load-balancing limitations exist for the reporting API: Administrative sessions: Reporting requires establishing a prior administrative session. Administrative sessions are tied to a specific Identikey Server and should therefore not be balanced between different Identikey Servers. Identikey Server Performance and Deployment Guide 22

Performance Baselines 4 Performance Baselines 4.1 Performance Setup A basic installation of Identikey Server was run on the machine, which includes the embedded PostgreSQL database. Performance data was gathered using the following methods: A digipass record import was performed. The time taken for the import was recorded. A user record import was performed and digipass were automatically assigned. The time taken for the import was recorded. A performance test was run for ten minutes, and repeated for each protocol used. 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. Hardware Quad core Intel Xeon CPU 4GB RAM Hardware Raid controller 3 * 7200RPM Hard Disk (RAID 5 volume) Operating Systems Windows 2008 32-bit, Red Hat Enterprise Linux 32-bit, or Red Hat Enterprise Linux 64-bit Database Embedded PostgreSQL Test data 20 000 Digipass 20 000 Users Protocols SOAP or RADIUS (including PAP, CHAP, MS-CHAP and MS-CHAPv2) Identikey Server Performance and Deployment Guide 23

Performance Baselines Auditing Auditing to text file or to embedded PostgreSQL database Reporting 4.2 Results 4.2.1 Import records 4.2.2 Authentication No reporting or reporting from embedded database. Windows (32-bit) Linux (32-bit) Linux (64-bit) Digipass import 4 minutes 56 seconds 6 minutes 33 seconds 5 minutes 49 seconds User import and assign 9 minutes 36 seconds 11 minutes 13 seconds 9 minutes 32 seconds Configuration Best rate Average Rate Audit to text file with no reporting Windows (32-bit) Linux (32-bit) Linux (64-bit) Windows (32-bit) Linux (32-bit) Linux (64-bit) SOAP 321 211 184 170 181 154 PAP 308 214 206 157 193 161 CHAP 326 223 208 159 201 164 MS-CHAP 309 219 204 132 202 159 MS-CHAPv2 308 216 195 144 144 157 Audit to database with no reporting SOAP 145 113 111 138 97 100 PAP 90 71 74 71 62 64 CHAP 90 72 75 72 62 65 MS-CHAP 90 74 73 72 63 64 MS-CHAPv2 90 74 80 72 62 64 Audit to database with reporting SOAP 129 97 99 120 89 76 PAP 101 64 65 64 56 57 CHAP 84 64 67 64 57 58 MS-CHAP 84 63 67 64 56 57 MS-CHAPv2 137 63 64 64 56 57 Identikey Server Performance and Deployment Guide 24

Performance Baselines 4.3 Variations Protocol The protocol to be used will depend primarily on your current network infrastructure. Results indicate that Identikey Server performs better using SOAP when using a local database and auditing to that database. When using RADIUS, all protocol types provide similar performance levels. Auditing and Reporting Auditing to database decreases performance on multiple-ik systems, consider an IK dedicated to auditing and other administrative tasks, or using a separate auditing database. Platform Performance is similar on Windows and Linux systems. 32-bit and 64-bit architecture yields similar results. 4.4 Recommendations The following recommendations are made based on the testing performed: With a database size of 20,000 users and DP, it is already recommended to have bulk administration and report generation on a separate server either a backup server or a dedicated server; up to about 2,000 users and DP, this is not likely to be necessary If your database size is getting toward 20,000 users and DP, consider a separate database if you have the resources and expertise to have a very fast, well maintained database; for the main database and for an audit database Consider using RAID-5 disk striping and faster disks if your sustained or peak transaction rate authentications plus other requests, eg. administration and digital signatures - is above 50 authentciations/second, unless the database and auditing are handled with fast, separate database servers. 4.5 Limitations An upper limit of 200 000 Digipass records is recommended for Identikey Server. Performance, in the sense of authentications/second, will be highly dependent on your hardware setup and deployment choices. Identikey Server Performance and Deployment Guide 25