IDENTIKEY Authentication Server Product Guide
Uploaded by
Mahmoud EmadIDENTIKEY Authentication Server Product Guide
Uploaded by
Mahmoud EmadIDENTIKEY Authentication Server
Product Guide
3.20
Disclaimer of Warranties and Limitations of Liabilities
Legal Notices
Copyright © 2008–2020 OneSpan North America, Inc. All rights reserved.
Trademarks
OneSpan™, DIGIPASS ® and CRONTO® are registered or unregistered trademarks of OneSpan North America Inc.,
OneSpan NV and/or OneSpan International GmbH (collectively "OneSpan") in the U.S. and other countries.
OneSpan reserves all rights to the trademarks, service marks and logos of OneSpan and its subsidiaries.
All other trademarks or trade names are the property of their respective owners.
Intellectual Property
OneSpan Software, documents and related materials (“Materials”) contain proprietary and confidential information.
All title, rights and interest in OneSpan Software and Materials, updates and upgrades thereof, including software
rights, copyrights, patent rights, industrial design rights, trade secret rights, sui generis database rights, and all other
intellectual and industrial property rights, vest exclusively in OneSpan or its licensors. No OneSpan Software or Mater-
ials 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 OneSpan in writing.
Disclaimer
OneSpan accepts no liability for the accuracy, completeness, or timeliness of content, or for the reliability of links to
and content of external or third party websites.
OneSpan shall have no liability under any circumstances for any loss, damage, or expense incurred by you, your com-
pany, or any third party arising from the use or inability to use OneSpan Software or Materials, or any third party mater-
ial made available or downloadable. OneSpan will not be liable in relation to any loss/damage caused by
modification of these Legal Notices or content.
Reservation
OneSpan reserves the right to modify these Notices and the content at any time. OneSpan likewise reserves the right
to withdraw or revoke consent or otherwise prohibit use of the OneSpan Software or Materials if such use does not
conform to the terms of any written agreement between OneSpan and you, or other applicable terms that OneSpan
publishes from time to time.
Contact us
Visit our website: https://www.onespan.com
Resource center: https://www.onespan.com/resource-center
Technical support and knowledge base: https://www.onespan.com/support
If there is no solution in the knowledge base, contact the company that supplied you with the OneSpan product.
Date last modified: 7/8/2020
Table of Contents
Table of Contents
1. Introduction 13
1.1. IDENTIKEY Authentication Server Documentation Suite 13
2. Overview 15
2.1. What is IDENTIKEY Authentication Server? 15
2.2. What is a DIGIPASS authenticator? 15
2.3. DIGIPASS Authenticator Types 16
2.4. DIGIPASS Licensing and Activation 23
2.5. Structure of IDENTIKEY Authentication Server 26
2.6. IDENTIKEY Authentication Server in a RADIUS environment 31
2.7. IDENTIKEY Authentication Server in a Web Environment 37
2.8. IDENTIKEY Authentication Server Administration Components 41
2.9. IDENTIKEY Authentication Server Data Model 43
2.10. Integrating with IDENTIKEY Authentication Server 46
2.11. SOAP SSL 48
2.12. PCI-DSS compliance 50
2.13. Maker–Checker Authorization 50
3. User Authentication 53
3.1. IDENTIKEY Authentication Server Authentication Process 53
3.2. Logging in with a DIGIPASS 53
3.3. Identifying the Component Record 54
3.4. Identifying a Policy 55
3.5. Looking Up and Checking the DIGIPASS User Account 56
3.6. Local Authentication 67
3.7. Back-End Authentication 84
3.8. Host Codes 92
IDENTIKEY Authentication Server 3.20 – Product Guide iii
Table of Contents
3.9. Supported RADIUS Protocols 93
3.10. Limitations of RADIUS Support in IDENTIKEY Authentication Server 93
4. Signature Validation 96
4.1. Signature Validation Process 96
4.2. Electronic Signature Application Types 98
4.3. Signature Verification Process 99
4.4. Policy Settings Relevant to Signature Validation 100
5. Software DIGIPASS Provisioning 102
5.1. Provisioning Overview 102
5.2. Provisioning Scenarios 105
5.3. Registration Process for Software DIGIPASS 123
5.4. Software DIGIPASS Activation Process 125
6. DIGIPASS Authentication for Windows Logon 128
6.1. Additional References 128
6.2. Online Authentication 128
6.3. Offline Authentication 129
6.4. Dynamic Component Registration (DCR) 132
6.5. Password Randomization 132
6.6. Password Synchronization Manager 133
7. EMV-CAP 135
7.1. Hardware Security Module 135
7.2. EMV-CAP Scenario 135
7.3. Licensing 135
7.4. Unsupported Standard IDENTIKEY Authentication Server Features 136
7.5. Primary Account Number (PAN) 136
7.6. EMV-CAP modes 136
IDENTIKEY Authentication Server 3.20 – Product Guide iv
Table of Contents
8. Hardware Security Module 137
8.1. Supported Hardware Security Modules 137
8.2. Licensing and Configuration 137
8.3. HSM Modules 137
8.4. HSM Migration 138
8.5. Unsupported Standard IDENTIKEY Authentication Server Features 138
8.6. Load Balancing and Failover 138
8.7. Cryptographic Keys 139
8.8. SafeNet HSMs 141
8.9. Thales nShield HSM 142
9. Administration 144
9.1. IDENTIKEY Authentication Server Administrator Accounts 144
9.2. List of Administration Interfaces in IDENTIKEY Authentication Server 145
9.3. Administration for Active Directory and ODBC 145
9.4. Administration Web Interface 146
9.5. Active Directory Users and Computers Extension 148
9.6. Tcl Command-Line Administration 150
9.7. Configuration Utility 151
9.8. Configuration Wizard 153
9.9. Other Administration Interfaces 154
9.10. Task Scheduling 154
9.11. Administration with Multiple IDENTIKEY Authentication Server Instances 155
9.12. Automating IDENTIKEY Authentication Server Administration Workflows 155
10. DIGIPASS User Accounts 157
10.1. Creating DIGIPASS User Accounts 157
10.2. Changes to Stored Static Passwords 159
IDENTIKEY Authentication Server 3.20 – Product Guide v
Table of Contents
10.3. Password Strength 159
10.4. Administration Privileges 162
10.5. DIGIPASS User Account Auto-Unlock 163
11. DIGIPASS 165
11.1. Importing DIGIPASS 165
11.2. Assigning DIGIPASS to Users 165
11.3. DIGIPASS Record Functions 167
11.4. DIGIPASS Reports 169
11.5. DIGIPASS Programming 169
11.6. DIGIPASS Record Settings 172
12. Components 178
12.1. Client Component Types 178
12.2. Server Components 180
13. Policies 182
13.1. Show Effective Settings 183
13.2. User-Specific Authentication Policy Overrides 184
13.3. Pre-Loaded Policies 185
14. Reporting 188
14.1. Reporting Features and Settings 188
14.2. Considerations for Reporting and Auditing 192
15. Wireless RADIUS 196
15.1. Fast Reconnect 196
15.2. Multiple Roaming Zones 198
16. IDENTIKEY Authentication Server and Active Directory 200
16.1. Schema Extensions 200
16.2. DIGIPASS Records 201
IDENTIKEY Authentication Server 3.20 – Product Guide vi
Table of Contents
16.3. Permissions Needed by IDENTIKEY Authentication Server for Active Directory 205
16.4. Administrative Permissions Used by IDENTIKEY Authentication Server 206
16.5. Active Directory Command-Line Utility (dpadadmin) 206
17. ODBC Data Store 208
17.1. Domains and Organizational Units 208
17.2. DIGIPASS Records Location 209
17.3. Permissions Needed by IDENTIKEY Authentication Server for ODBC 213
17.4. ODBC Database Command-Line Utility (dpdbadmin) 214
17.5. Additional ODBC Databases 214
17.6. Multiple Instances of IDENTIKEY Authentication Server Using ODBC 215
17.7. Replication 216
17.8. Cache Persistence 220
18. Licensing 222
18.1. Component Licenses 222
18.2. Evaluation License 223
18.3. Obtaining and Loading a License Key 224
19. Monitoring 226
20.1. Performance Monitoring 227
20.2. Health Check 229
21.1. System Monitoring 230
22. User Dashboard 232
22.1. Working with the User Dashboard 232
22.2. View Audit Message Page 236
22.3. Generating Reports via the Reports Tab 237
23. Auditing and Tracing 238
23.1. Audit Viewer 239
IDENTIKEY Authentication Server 3.20 – Product Guide vii
Table of Contents
23.2. Audit Message Types 240
23.3. Secure Auditing 240
23.4. Deleting Audit Data 241
23.5. Tracing 242
24. Message Delivery Component (MDC) 243
24.1. Gateway Definition 244
24.2. Gateway Types (by Protocol) 244
24.3. MDC profiles 244
25. Upgrading IDENTIKEY Authentication Server and Migrating Server Data 245
25.1. Upgrading IDENTIKEY Authentication Server Software and Updating Static Server Configuration 245
25.2. Migrating from Software Security Module (SSM) to Hardware Security Module (HSM) 246
25.3. Migrating Server Data 246
IDENTIKEY Authentication Server 3.20 – Product Guide viii
Table of Contents
Illustration Index
Image 1: DIGIPASS 260 17
Image 2: DIGIPASS 270 XPress 17
Image 3: DIGIPASS 301 Comfort Voice 17
Image 4: DIGIPASS 560 17
Image 5: DIGIPASS 760 18
Image 6: DIGIPASS GO 215 18
Image 7: DIGIPASS 785 18
Image 8: DIGIPASS GO 3 19
Image 9: DIGIPASS GO 6 19
Image 10: DIGIPASS GO 7 19
Image 11: DIGIPASS GO 100 19
Image 12: DIGIPASS 810 19
Image 13: DIGIPASS 855 19
Image 14: DIGIPASS 875R 20
Image 15: DIGIPASS Nano 22
Image 16: DIGIPASS 110 22
Image 17: Structure of IDENTIKEY Authentication Server 27
Image 18: Stand-alone: RADIUS Attributes from DIGIPASS user account 33
Image 19: Stand-alone: No RADIUS Attributes Required 33
Image 20: IDENTIKEY Authentication Server with Wireless RADIUS 34
Image 21: IDENTIKEY Authentication Server with RADIUS Server Acting as a Proxy 35
Image 22: RADIUS Server as Back-End Server (Users Log In with OTP Only) 36
Image 23: RADIUS Server as Back-End Server (Users Log In with Both Password and OTP) 37
Image 24: IDENTIKEY Authentication Server in an IIS Web Environment (OTP-Only) 39
Image 25: IDENTIKEY Authentication Server in an IIS Web Environment (OTP+Password Login) 40
Image 26: Maker–Checker Authorization Workflow 51
Image 27: Name resolution with ODBC database 57
Image 28: Name resolution with ODBC database and Active Directory back end 58
IDENTIKEY Authentication Server 3.20 – Product Guide ix
Table of Contents
Image 29: Name resolution with Active Directory storage 59
Image 30: Dynamic User Registration (Process) 66
Image 31: Server PIN States and Actions 72
Image 32: Multiple DIGIPASS Assignments 78
Image 33: RADIUS Attributes Overview 82
Image 34: Custom User Attributes Overview 83
Image 35: back-end authentication for Active Directory 89
Image 36: Back-End Authentication for NetIQ eDirectory 91
Image 37: Steps of Provisioning 103
Image 38: Mobile Authenticator Studio Offline Activation Process 107
Image 39: Mobile Authenticator Studio Online Activation Process 109
Image 40: DIGIPASS for Web Scenario 1 Process 114
Image 41: DIGIPASS for Web Scenario 2 Process 116
Image 42: DIGIPASS for Web Scenario 3 Process 118
Image 43: DIGIPASS 110 Scenario 1 120
Image 44: DIGIPASS 110 Scenario 2 122
Image 45: Software DIGIPASS Registration Process 123
Image 46: Software DIGIPASS Activation Process 126
Image 47: DIGIPASS Authentication for Windows Logon Online Authentication 129
Image 48: DIGIPASS Authentication for Windows Logon Offline Authentication 130
Image 49: DIGIPASS 810 135
Image 50: SafeNet Cryptographic Keys Allocated by Token Name and Slot ID 141
Image 51: Administration Web Interface 146
Image 52: Configuration Utility 152
Image 53: Policy Inheritance Example 182
Image 54: Wireless RADIUS Components 196
Image 55: Fast reconnect Overview 197
Image 56: Roaming Wireless Fast Reconnection 198
Image 57: Roaming Wireless Fast Reconnection – Roaming Zones 199
IDENTIKEY Authentication Server 3.20 – Product Guide x
Table of Contents
Image 58: DIGIPASS Record Locations - DIGIPASS Pool 203
Image 59: DIGIPASS Record Locations - Parent Organizational Unit 204
Image 60: DIGIPASS Record Locations - Individual Organizational Units 205
Image 61: Domains and Organizational Units 209
Image 62: DIGIPASS Record Locations – Domain Root 211
Image 63: DIGIPASS Record Location – Parent Organizational Unit 212
Image 64: DIGIPASS Record Locations – Individual Organizational Units 213
Image 65: Additional ODBC databases 215
Image 66: Multiple IDENTIKEY Authentication Server Using Single Database 216
Image 67: Replication between a Primary and Backup IDENTIKEY Authentication Server instance 217
Image 68: Replication between Primary, Backup, and Disaster Recovery in IDENTIKEY Authentication Server 218
Image 69: Replication between three IDENTIKEY Authentication Server instances 219
Image 70: Complex IDENTIKEY Authentication Server Replication Scenario 220
Image 71: Adding Filter in Performance Monitoring 228
Image 72: Audit System Overview 238
Image 73: Audit Viewer 240
IDENTIKEY Authentication Server 3.20 – Product Guide xi
Table of Contents
Table Index
Table 1: Login methods 54
Table 2: User name resolution in IDENTIKEY Authentication Server 56
Table 3: Server Settings Regulating Server PINs 70
Table 4: OTP Authentication for Scenarios Involving Multiple and Single DIGIPASS Applications 79
Table 5: Supported User Logon Format for NetIQ eDirectory 90
Table 6: Provisioning Scenarios 105
Table 7: Supported EMV-CAP modes in IDENTIKEY Authentication Server 136
Table 8: Active Directory Users and Computers Extension vs Administration Web Interface 146
Table 9: Time-and event-based modes of DIGIPASS Application 170
Table 10: Backup Virtual Mobile Authenticator Policy/ DIGIPASS Settings 173
Table 11: Server PIN Settings 174
Table 12: DIGIPASS Options 174
Table 13: Backup Virtual Mobile Authenticator Sample Guidelines 176
Table 14: Summary of DIGIPASS record location options 202
Table 15: dpadadmin Commands 206
Table 16: dpdbadmin Commands 214
Table 17: Target requirements 231
Table 18: Dashboard Used Clients - Displayed Fields 233
Table 19: Report Definition Criteria 237
Table 20: Audit Message Types 240
IDENTIKEY Authentication Server 3.20 – Product Guide xii
1. Introduction
1. Introduction
The IDENTIKEY Authentication Server Product Guide introduces the features and concepts of IDENTIKEY Authentic-
ation Server and explains various usage options. This book provides a comprehensive overview of IDENTIKEY
Authentication Server and its features.
Warning
Components or features described in this document may need to be configured to meet the standards of the Gen-
eral Data Protection Regulation (GDPR). If your organization is collecting or in any capacity processing data on cit-
izens of a European Union country, your organization is subject to the GDPR. For more information about GDPR
compliance, refer to the IDENTIKEY Authentication Server General Data Protection Regulation Compliance Guide.
1.1. IDENTIKEY Authentication Server Documentation Suite
The following product documentation is 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 Installation Guide for Windows: provides comprehensive instructions
about installing IDENTIKEY Authentication Server on a Windows platform.
n IDENTIKEY Authentication Server Installation Guide for Linux: provides comprehensive instructions about
installing IDENTIKEY Authentication Server on a supported Linux distribution.
n IDENTIKEY Authentication Server Administrator Guide: in-depth information about the administration and
management 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 about common deploy-
ment models and performance statistics.
n IDENTIKEY Authentication Server Release Notes: latest information about corresponding IDENTIKEY
Authentication Server releases.
n IDENTIKEY Authentication Server General Data Protection Regulation Compliance Guide: provides general
information about the EU General Data Protection Regulation (GDPR), its implications on IDENTIKEY
Authentication Server, its components and side-products, and provides instructions to achieve GDPR com-
pliance where additional adaptations or procedures are required.
n IDENTIKEY Authentication Server Data Migration Guide: provides comprehensive information about the vari-
ous paths available when updating IDENTIKEY Authentication Server to a higher version.
n IDENTIKEY Authentication Server SDK Programmer's Guide: in-depth information required to develop using
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 Java
n IDENTIKEY Authentication Server SDK Programmer's Guide for .NET
IDENTIKEY Authentication Server 3.20 – Product Guide 13
1. Introduction
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
n Mobile Authenticator Getting Started Guide: provides general information on the Mobile Authenticator and
how to install it.
n DIGIPASS Gateway Getting Started Guide: provides general information on DIGIPASS Gateway and how to
install it.
n DIGIPASS Gateway Integration Guide: provides information how to configure DIGIPASS Gateway and how
to integrate it with mobile devices.
n Push NotificationGetting Started Guide: provides information about the Push Notification feature in general
and details on the required components and the system setup.
1.1.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.1.2. 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.
IDENTIKEY Authentication Server 3.20 – Product Guide 14
2. Overview
2. Overview
This section provides a high-level description of IDENTIKEY Authentication Server and its related technologies.
2.1. What is IDENTIKEY Authentication Server?
IDENTIKEY Authentication Server is a server product designed to support the deployment, use, and administration
of OneSpan DIGIPASS technology. IDENTIKEY Authentication Server can be easily integrated with existing applic-
ations using a Software Development Kit (SDK).
IDENTIKEY Authentication Server supports the following primary functions:
n DIGIPASS one-time password authentication
n DIGIPASS signature validation
n Software DIGIPASS provisioning
n Administration and reporting
n Auditing
IDENTIKEY Authentication Server is designed to be easily usable with web applications, and also features an Admin-
istration Web Interface.
2.2. What is a DIGIPASS authenticator?
A DIGIPASS authenticator is a device for providing one-time passwords (OTPs) and Electronic Signatures to a user.
An organization can provide its users with DIGIPASS authenticators to ensure that the users log in to secure sys-
tems via strong authentication. The DIGIPASS authenticator provides the OTPs and the DIGIPASS users can use
these OTPs instead of or in addition to a static password for the login. With devices that support this functionality,
authentication transactions can be performed via the Secure Channel feature of IDENTIKEY Authentication Server
and DIGIPASS authenticators. For more information about Secure Channel, see 2.4.5. Secure Channel Feature.
In addition, a DIGIPASS authenticator can also be used to sign transaction data. Here, the user manually enters key
details of the transaction into the DIGIPASS authenticator or, with devices that support this functionality, scans an
image- in form of a QR code or a color QR code - provided on the transaction page, and receives a signature. The
user then enters that signature into a transaction confirmation page to confirm that the transaction is authorized.
Virtual Mobile Authenticator is a mechanism where an OTP is generated by the server and sent to the user's mobile
phone or email account. In this case, a physical DIGIPASS device is not needed.
A software DIGIPASS authenticator may be installed as a DIGIPASS Application onto an existing non-OneSpan plat-
form (such as a computer, smartphone, or other mobile device). It can be used to generate an OTP or a signature
in the same way as a physical DIGIPASS authenticator.
IDENTIKEY Authentication Server 3.20 – Product Guide 15
2. Overview
2.3. DIGIPASS Authenticator Types
Each DIGIPASS authenticator is programmed with at least one DIGIPASS Application and a unique secret . The
DIGIPASS Application uses this unique secret when generating a one-time password (OTP) or an Electronic Sig-
nature.
Each type of DIGIPASS Application generates OTPs from different data, and in slightly different ways:
Response-Only
Creates an OTP based on the current date and time or on the number of uses (i.e. events).
Challenge/Response
Creates an OTP (also referred to as a response) based on a numerical challenge given on a login page. This
challenge may be either of two things:
n Custom-created for the specific DIGIPASS authenticator
n A randomly-created challenge
The OTP may also be based on the date and time.
Signature
Electronic Signature DIGIPASS Applications are typically used in online banking. The DIGIPASS authenticator
creates a unique code – i.e. an Electronic Signature – based on a number of transaction data fields entered
plus (optionally) the date and time or events.
Multi-Mode
A Multi-Mode DIGIPASS authenticator can be used on all of the above modes. This setting is used mainly for
DIGIPASS for Web (see 2.3.2.1. Software DIGIPASS Types).
2.3.1. Hardware DIGIPASS Authenticator
A hardware DIGIPASS authenticator is a device specifically designed to create OTPs. Each hardware
DIGIPASS authenticator can be used for the following DIGIPASS application types:
n Response-Only
n Challenge/Response
n Signature
IDENTIKEY Authentication Server 3.20 – Product Guide 16
2. Overview
2.3.1.1. E-Signature DIGIPASS Authenticator
DIGIPASS authenticator devices of this type are typically capable of supporting more than one DIGIPASS Application;
some of these authenticators can be programmed so that a PIN must be entered before they generate a one-time
password (OTP) or an Electronic Signature.
Image 1: DIGIPASS 260 Image 2: DIGIPASS 270 XPress
Image 3: DIGIPASS 301 Comfort Voice Image 4: DIGIPASS 560
DIGIPASS 760 protects online banking services by allowing the bank to establish a secure optical communication
channel with the client. The device uses a unique visual challenge contained in a graphical cryptogram, a color QR
code, consisting of a matrix of colored dots. The user scans the color QR code with the device's built-in camera to
generate the signatures for activations and transactions.
IDENTIKEY Authentication Server 3.20 – Product Guide 17
2. Overview
Image 5: DIGIPASS 760
DIGIPASS GO 215 and DIGIPASS 785 protect online banking services by allowing the bank to establish a secure com-
munication channel with the client using Bluetooth low energy (BLE).
Image 6: DIGIPASS GO 215 Image 7: DIGIPASS 785
2.3.1.2. Single-Button DIGIPASS Authenticator
This is the simplest type of a DIGIPASS authenticator. A DIGIPASS authenticator without a keypad has a triggering
mechanism – typically an action, e.g. pressing a button. That action triggers the generation of a one-time pass-
word (OTP). Single-button DIGIPASS authenticator devices only have one DIGIPASS Application, which is always
Response-Only.
IDENTIKEY Authentication Server 3.20 – Product Guide 18
2. Overview
Image 8: DIGIPASS GO 3 Image 9: DIGIPASS GO 6
Image 10: DIGIPASS GO 7 Image 11: DIGIPASS GO 100
2.3.1.3. DIGIPASS Card Readers
DIGIPASS card readers provide two-factor authentication based on smart card technology in a similar way to other
hardware DIGIPASS authenticator devices. The smart card itself provides the 'secret' used to generate a one-time
password (OTP) and Electronic Signature.
IDENTIKEY Authentication Server supports EMV-CAP compliant smart cards and card readers (see 7. EMV-CAP).
Image 12: DIGIPASS 810 Image 13: DIGIPASS 855
IDENTIKEY Authentication Server 3.20 – Product Guide 19
2. Overview
Image 14: DIGIPASS 875R
2.3.2. Software DIGIPASS Authenticator
Software DIGIPASS authenticators are software versions of DIGIPASS that provide authentication and signature func-
tions for mobile devices and web browsers. They generate a one-time password or Electronic Signature for you in
the same way as a hardware DIGIPASS.
A software DIGIPASS authenticator may be installed as a DIGIPASS Application onto an existing non-OneSpan plat-
form (such as a computer, smartphone, or other mobile device). This effectively makes the device emulate a hard-
ware DIGIPASS. The user then accesses the installed DIGIPASS Application to obtain a one-time password (OTP) or
Electronic Signature. For more information about hardware DIGIPASS, refer to 2.3.1. Hardware
DIGIPASS authenticator. To be ready for use, each software DIGIPASS requires:
n Software installed on the client device
n A unique activation code
Once installed on a host device, software DIGIPASS will need to be activated via an activation code. Once activ-
ated, the device can then be used to generate one-time passwords and Electronic Signatures. Software delivery
and activation of the software DIGIPASS authenticator takes place in the course of the provisioning process - refer
to Chapter 5. Software DIGIPASS Provisioning for more information on this.
A software DIGIPASS authenticator typically supports the following DIGIPASS Application types:
n Response-Only
n Challenge/Response
n Signature
The distribution of a software DIGIPASS authenticator is controlled by IDENTIKEY Authentication Server using pro-
visioning scenarios (see 5. Software DIGIPASS Provisioning).
IDENTIKEY Authentication Server 3.20 – Product Guide 20
2. Overview
2.3.2.1. Software DIGIPASS Types
The following software DIGIPASS types are supported by the Provisioning function in IDENTIKEY Authentication
Server:
Mobile Authenticator Studio
Mobile Authenticator Studio is a customizable mobile app facilitating two-factor authentication as well as e-
signature generation to address the security risks of mobile and online applications. It is available for Android,
iOS, and Windows Phone mobile devices.
Mobile Authenticator
The Mobile Authenticator is activated with a color QR code, and can be protected either with fingerprint recog-
nition or a PIN code, depending on the available mobile device functionalities. Mobile Authenticator can con-
tain multiple DIGIPASS instances and can be installed on several mobile devices, allowing the use of multiple
devices for the login process. For more detailed information, refer to the Mobile Authenticator Getting Started
Guide.
The Mobile Authenticator is used for push–notification-based authentication. For more information on this,
refer to 2.4.6. Push Notification via the Mobile Authenticator and 3.6.2.6. Push– Notification- Based
Authentication Process. For detailed information on the Push Notification feature, required components, and
the setup with IDENTIKEY Authentication Server and its components , refer to the Push Notification Getting
Started Guide.
Mobile Security Suite
Mobile Security Suite is a software development kit (SDK) to natively integrate application security, two-factor
authentication, and electronic signatures into mobile applications developed by OneSpan customers. It con-
sists of a library of dedicated APIs to strengthen mobile application security and facilitate mobile transactions
across multiple user devices. Mobile Security Suite supports Android, iOS, and Windows Phone. For more
detailed information, refer to the Mobile Security Suite documentation suite.
DIGIPASS for Web
DIGIPASS for Web is a Java applet that runs on an internet browser using cookies for data storage. For this
applet to work, cookies must be enabled on your internet browser. DIGIPASS for Web will also generate aone-
time password or Electronic Signature on demand. DIGIPASS for Web supports the Multi-Mode DIGIPASS Applic-
ation type.
Hybrid DIGIPASS: DIGIPASS 110 and DIGIPASS 760
DIGIPASS 110 and DIGIPASS 760 are hybrid devices, composed of a hardware and a software component.
IDENTIKEY Authentication Server 3.20 – Product Guide 21
2. Overview
2.3.3. DIGIPASS Nano
The DIGIPASS Nano consists of a thin film that users can place on top of any SIM card, turning the phone into a
mobile security device capable of generating an OTP or Electronic Signature.
Image 15: DIGIPASS Nano
2.3.4. DIGIPASS 110
DIGIPASS 110 is a hybrid DIGIPASS authenticator combining the security of a hardware device with the portability of
a software DIGIPASS authenticator. This authenticator consists of a secure USB stick used with a Java applet on
the user's computer. It contains the cryptographic information used to generate a one-time password (OTP) for the
user on demand.
The distribution of the Java applet used with DIGIPASS 110 is handled by IDENTIKEY Authentication Server using pro-
visioning scenarios similar to software DIGIPASS authenticators (see 5. Software DIGIPASS Provisioning).
Image 16: DIGIPASS 110
2.3.5. Virtual Mobile Authenticator
Virtual Mobile Authenticator can be used instead of a hardware DIGIPASS authenticator, or as a backup mechanism
when users lose their hardware DIGIPASS authenticator.
Using Virtual Mobile Authenticator means that a user may receive a one-time password (OTP) via:
IDENTIKEY Authentication Server 3.20 – Product Guide 22
2. Overview
n Email
n SMS (over a mobile phone)
n Voice message (over a landline or mobile phone)
There are two forms of Virtual Mobile Authenticator available:
n Primary Virtual Mobile Authenticator. Treated by IDENTIKEY Authentication Server almost identically to hard-
ware and software DIGIPASS authenticator – a record of each Primary Virtual Mobile Authenticator must be
imported into the data store, and may then be assigned to a user automatically or manually. Users will typ-
ically log in with their user ID and static password, have an OTP sent to their phone or email account, and
then enter the received OTP in the second stage of their login.
n Backup Virtual Mobile Authenticator. This feature allows users to request an OTP sent to their phone or
email account if they do not have their usual DIGIPASS authenticator at hand. It may be limited by number
of uses or days of use, e.g. users may be limited to 2 days usage, after which they will again need to use
their usual DIGIPASS authenticator to log in.
2.4. DIGIPASS Licensing and Activation
2.4.1. Standard Licensing and Activation
The standard licensing model applies to models of the DIGIPASS authenticator that are pre-provisioned ex factory,
and software DIGIPASS using standard one-step activation.
The standard activation process involves generating an activation code and sending it to a software DIGIPASS sep-
arately or as part of the full activation data. Even though generating the activation data is part of the first-time activ-
ation process, you can also re-generate and re-send the activation data for already activated authenticators,
which may be required for security purposes.
Warning
Generating the activation data of or sending the activation data to an activated authenticator will invalidate the
current activation; in this case, the user will no longer be able to log in with their authenticator.
2.4.2. DIGIPASS Multi-Device Licensing and Activation
IDENTIKEY Authentication Server supports Multi-Device Licensing and Multi-Device Activation. This licensing and
activation model applies to the following models of the DIGIPASS authenticator:
n E-signature DIGIPASS: DIGIPASS 760
n Software DIGIPASS: Mobile Authenticator Studio and Mobile Security Suite
Note
Certain Multi-Device Licensing, Multi-Device Activation functionalities and the Secure Channel feature are aimed
at the banking security market only. This implies that certain of these functionalities will not be available for
IDENTIKEY Authentication Server 3.20 – Product Guide 23
2. Overview
typical enterprise security deployments.
Warning
The Multi-Device Licensing and Multi-Device Activation functionality using the Secure Channel feature requires a
SOAP provisioning and / or SOAP signature license!
With the Multi-Device Licensing model and its one-to-one relationship between a user account and a DIGIPASS
serial number license, a user account can optionally be bound to several DIGIPASS instances. Multi-Device Activ-
ation, which is an activation process in two steps, guarantees that only the intended end user can perform the
device activation.
Note
Multi-Device Licensing and Multi-Device Activation are not supported, if IDENTIKEY Authentication Server is con-
figured to use Active Directory (AD) as data storage.
2.4.3. Multi-Device Licensing
With the Multi-Device Licensing model, each DIGIPASS serial number corresponds to a unique DIGIPASS license;
consequently, for each DIGIPASS device compliant with the Multi-Device Licensing model, the corresponding .dpx
file contains one DIGIPASS master activation application for each DIGIPASS license. These DIGIPASS instances are
represented in IDENTIKEY Authentication Server as DIGIPASS with a single DIGIPASS master activation application.
One DIGIPASS license allows to instantiate several DIGIPASS instances bound to the same DIGIPASS license.
DIGIPASS instances are not different from DIGIPASS activated in the standard process with regard to the rep-
resentation of DIGIPASS applications. IDENTIKEY Authentication Server creates the DIGIPASS instance(s) for a par-
ticular license during the Multi-Device Activation process.
The number of instances that can be activated for each DIGIPASS license is limited to a predefined threshold which
is configured by OneSpan at the time of order. A maximum number of 99 instances can be configured, and each
DIGIPASS instance can have from 1 to 8 DIGIPASS authentication or e-signature application(s). These DIGIPASS
instances are represented in IDENTIKEY Authentication Server as DIGIPASS with the same base serial number as
the bound DIGIPASS license, appended with the instance sequence number.
2.4.4. Multi-Device Activation
In the Multi-Device Activation process, two separate activation messages are used for activating the device(s). This
serves to guarantee that only the intended end user, and not an adversary who has intercepted one of the mes-
sages, can perform the activation. Multi-Device Activation is a different process from the standard software
DIGIPASS activation and requires DIGIPASS devices and .dpx files compliant with the Multi-Device Licensing model.
When a compliant DIGIPASS device is activated, settings and secrets are written into the device.
IDENTIKEY Authentication Server 3.20 – Product Guide 24
2. Overview
2.4.4.1. Master activation applications and activation messages
The Multi-Device Activation process uses the master activation application which contains an individual master
activation key for each DIGIPASS license. Every DIGIPASS license must be linked to a single user account. Two sep-
arate activation messages are used in the activation process; the first activation message (Activation Message 1)
allows activating a DIGIPASS license in the device, the second activation message (Activation Message 2) allows
activating a DIGIPASS instance of a license in the device.
Note
Both activation messages should be delivered to the end user via authentic channels. For instance, Activation
Message 1 should be delivered via a secure letter or e-mail and Activation Message 2 should be delivered via the
online banking application.
Activation Message 1 may be used several times to allow activation of multiple DIGIPASS instances (of one
DIGIPASS license) on multiple DIGIPASS devices, if necessary. The validity period for Activation Message 1 is con-
figurable in your IDENTIKEY Authentication Server policy. On the other hand, Activation Message 2 can be used for
effective activation for one DIGIPASS instance only.
Note
Each DIGIPASS license will be used several times for activation of several DIGIPASS instances (in several DIGIPASS
devices) for one user account; however, only one license will be consumed for the activation of the different
DIGIPASS instances for one user account.
2.4.4.2. DIGIPASS instance sequence number
With each activation of a new DIGIPASS instance, IDENTIKEY Authentication Server will generate new DIGIPASS
applications. A sequence number will be incremented for each new DIGIPASS instance issued from the same
license. The number of instances which can be issued from a license will be limited to a pre-defined threshold
between 1 and 99 (configured by OneSpan at the time of order). The different DIGIPASS instances of one user
share the base serial number (the serial number of the DIGIPASS license), but will be appended with a unique
sequence number for the DIGIPASS instance. The keys of the DIGIPASS instance applications will be different for
each instance.
2.4.5. Secure Channel Feature
Secure Channel is an optional feature applicable to DIGIPASS devices compliant with the Multi-Device Activation
process (in the context of Multi-Device Licensing). The optional use of the secure channel feature after activation
of a DIGIPASS instance allows protecting the messages that are exchanged between the server- and the client-
side.
Note
The secure channel will be usable only if the Secure Channel feature has been ordered from and configured by
OneSpan at the time of order.
IDENTIKEY Authentication Server 3.20 – Product Guide 25
2. Overview
The Secure Channel feature applies a new protocol that uses payload keys to protect the confidentiality and
authenticity of the message's payload. A single master payload key is shared among all DIGIPASS instances linked
to a certain DIGIPASS license, enabling the end user to transparently use multiple DIGIPASS devices to answer the
transaction request message.
The Secure Channel feature requires the mandatory provisioning of a payload key represented on the server-side
by a payload key BLOB. In this case, first a payload key will have to be generated once for each DIGIPASS license.
The different DIGIPASS instances activated from one DIGIPASS license must share the same payload key. After the
activation, the payload key will protect the request and deactivation messages for exchange between the server
and the client devices that have been activated using a particular DIGIPASS license (for a particular user account).
The parameters used to generate the request body for Secure Channel messages can be configured via the Secure
Channel tab in the policy properties page of the Administration Web Interface.
Note
The Secure Channel tab is not displayed for Active Directory storage-based deployments of IDENTIKEY Authentic-
ation Server.
If the Secure Channel feature has not been ordered, IDENTIKEY Authentication Server will not generate and pro-
vision any payload key.
2.4.6. Push Notification via the Mobile Authenticator
IDENTIKEY Authentication Server supports authentications via Push Notification - this authentication method uses a
push mode to enable the Mobile Authenticator on a mobile device to authenticate the user. Refer to 3.6.2.6. Push–
Notification-Based Authentication Process for an overview of the push–notification-based authentication process.
For detailed information on the Mobile Authenticator, refer to the Mobile Authenticator and Mobile Authenticator
Studio product documents; for detailed information on the Push Notification feature and required components,
refer to the Push Notification Getting Started Guide , which is part of the IDENTIKEY Authentication Server doc-
umentation suite. For detailed information how to activate the Mobile Authenticator and the required steps to
upgrade the Mobile Authenticator to enable Push Notification, refer to the OneSpan User Websites Administrator
Guide.
2.5. Structure of IDENTIKEY Authentication Server
The following diagram displays the basic structure of IDENTIKEY Authentication Server and the components it inter-
acts with, such as corporate and remote access clients, remote management applications, custom web applic-
ations, and back-end systems.
IDENTIKEY Authentication Server 3.20 – Product Guide 26
2. Overview
Image 17: Structure of IDENTIKEY Authentication Server
IDENTIKEY Authentication Server 3.20 – Product Guide 27
2. Overview
2.5.1. Web Applications
IDENTIKEY Authentication Server provides support for web applications through an SDK based on the standard
SOAP protocol. These applications may cover operational tasks such as authentication and signature validation,
provisioning of Software DIGIPASS or administration of DIGIPASS Authentication for Microsoft ADFS.
SOAP over HTTPS is supported, versions 1.1 and 1.2. 'Document Literal' binding is used. A variety of SOAP client
SDKs have been tested.
2.5.2. Corporate and Remote Access Clients
Some of the client components of IDENTIKEY Authentication Server also use the SOAP protocol for communication
like the DIGIPASS Authentication Modules and DIGIPASS Authentication for Windows Logon.
IDENTIKEY Authentication Server supports the RADIUS protocol (according to RFC 2865) for remote network access
authentication. Some applications are written using RADIUS as an authentication protocol, and these applications
will also be supported.
The SEAL protocol is a proprietary OneSpan protocol used by some of the OneSpan authentication modules; this
includes Citrix Web Interface and DIGIPASS Authentication for Windows Logon version 1.x.
2.5.3. IDENTIKEY Authentication Server as a Service Provider
The IDENTIKEY Authentication Server is a service which receives and processes requests from the various client
components. It may refer to a back-end system for a part of the processing tasks.
IDENTIKEY Authentication Server has a modular architecture incorporating the following key concepts:
Communicator Modules
IDENTIKEY Authentication Server provides a communicator module for each protocol for which it can receive
and handle requests. Each communicator module can be enabled or disabled as required, subject to support
in the server license.
The following communicator modules are present:
n SOAP (requires a license option)
n RADIUS (requires a license option)
n SEAL (does not require a license option)
IDENTIKEY Authentication Server 3.20 – Product Guide 28
2. Overview
Scenario Modules
For each major group of functionality in the IDENTIKEY Authentication Server, a Scenario module is present.
Each scenario can be enabled or disabled as preferred, subject to support in the license. The following scen-
arios are present:
n Authentication (requires a license option)
n Signature Validation (requires a license option)
n Provisioning (requires a license option)
n Administration (does not require a license option)
n Reporting (does not require a license option)
n Replication (does not require a license option)
n Audit (does not require a license option)
n Configuration (does not require a license option)
n EMV-CAP (requires a license option)
Back-End Systems
A back-end system is used as an authority for user accounts and static passwords, before a user account is
created in IDENTIKEY Authentication Server and the user starts to use a DIGIPASS authenticator. A RADIUS
server may be used for both back-end authentication and returning RADIUS attributes. For more information,
see 3.7. Back-End Authentication.
Data Synchronization Tools
User accounts can be created on IDENTIKEY Authentication Server and synchronized using the following tools:
n LDAP Synchronization Tool synchronizes user information on IDENTIKEY Authentication Server with
external LDAP databases. For more information, refer to the LDAP Synchronization Tool Guide.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that LDAP Syn-
chronization Tool is used to synchronize user information from any LDAP data store with any IDENTIKEY
Authentication Server data store. To be GDPR-compliant, the following requirements must be met:
n Secure version of LDAP (LDAPS) is used.
n SEAL protocol used for communication with IDENTIKEY Authentication Server is SSL enabled.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection
Regulation Compliance Guide.
n Password Synchronization Manager automatically updates the static password on IDENTIKEY Authentic-
ation Server when a user has changed the Windows password (see 6.6. Password Synchronization Man-
ager).
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), you need to secure
IDENTIKEY Authentication Server 3.20 – Product Guide 29
2. Overview
the communication between Password Synchronization Manager and IDENTIKEY Authentication Server
via SSL to be GDPR-compliant. Each IDENTIKEY Authentication Server configuration can be updated to
use encrypted communication via the Use SSL option in the password filter configuration of the PSM
Remote Configuration Manager.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection
Regulation Compliance Guide.
Data Store
IDENTIKEY Authentication Server can use Active Directory or a supported ODBC-compliant database to store
administration and configuration data.
An embedded MariaDB database is also included in the IDENTIKEY Authentication Server installation package.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), be aware that when
selecting the embedded MariaDB during installation, you will be prompted to choose whether or not to use
encryption. By selecting Yes, IDENTIKEY Authentication Server will use data-at-rest encryption for the data-
base, and use ODBC connection encryption by default.
When selecting the Advanced installation option and not opting for a MariaDB database, you are respons-
ible for protecting the database and the connections to it.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regu-
lation Compliance Guide.
Hardware Security Module (HSM)
A Hardware Security Module (HSM) may be used to safeguard data (see 8. Hardware Security Module ).
Note
Hardware Security Module support is only available when IDENTIKEY Authentication Server is using an ODBC-com-
pliant database.
2.5.4. OneSpan User Websites
The OneSpan User Websites enable users to perform management and other tasks that are not available during
usual login, such as user registration, DIGIPASS assignment and activation, PIN change, and Virtual Mobile
Authenticator OTP (one-time password) requests. You can provide and restrict access to functionality as needed,
and customize any cosmetic part of OneSpan User Websites to meet your corporate design and text requirements.
If you want to use your own web pages with the OneSpan User Websites business logic, you can easily do so by
implementing the correct HTML POST forms with all the required input fields.
For more information, refer to the OneSpan User Websites Administrator Guide.
IDENTIKEY Authentication Server 3.20 – Product Guide 30
2. Overview
2.5.5. DIGIPASS Gateway
DIGIPASS Gateway is a service that allows IDENTIKEY Authentication Server to interact with compatible DIGIPASS
authenticators. It is used in the following processes:
n Multi-Device Activation: DIGIPASS Gateway is used for transmitting activation data to compliant DIGIPASS
authenticators.
For more information about Multi-Device Activation, see 2.4. DIGIPASS Licensing and Activation.
n Upgrading to Push Notification: This procedure is required after an upgrade of the Mobile Authenticator
from a version that does not support the Push Notification feature. For more information about the
upgrade procedure, refer to the IDENTIKEY Authentication Server Administrator Guide and the OneSpan
User Websites Administrator Guide.
n Authentication via Push Notification using the Mobile Authenticator (see 3.6.2.6. Push–Notification-Based
Authentication Process).
For more information about Push Notification and its required components, refer to the Push Notification Getting
Started Guide . For more information about integrating DIGIPASS Gateway, refer to the respective product doc-
umentation.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), ensure to run DIGIPASS Gate-
way on an encrypted disk. Currently, the DIGIPASS Gateway database does not provide encryption.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
2.6. IDENTIKEY Authentication Server in a RADIUS environment
IDENTIKEY Authentication Server can be used in a RADIUS environment in a number of ways, depending on your
company's requirements.
In the RADIUS protocol, attributes are used for authorization and configuration of the remote access session in
many cases. IDENTIKEY Authentication Server can return authorization attributes from the DIGIPASS user account;
alternatively, a separate RADIUS server can provide these attributes instead.
In many cases, a RADIUS Client may be a dial-up Network Access Server (NAS), firewall/VPN appliance, Wireless
Access Point, or another device that uses the RADIUS protocol for user authentication. Some software applications
can also use RADIUS for authentication, and can therefore also act as RADIUS Clients.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that for being GDPR-
IDENTIKEY Authentication Server 3.20 – Product Guide 31
2. Overview
compliant, you must set up an encrypted VPN tunnel such as IPsec.
For more information on GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regulation
Compliance Guide.
Supported password protocols
The scenarios described in the following sections can be implemented with these supported password protocols:
n PAP
n CHAP
n MSCHAP
n MSCHAP2
Warning
When integrating IDENTIKEY Authentication Server into a RADIUS environment to provide authentication services,
DIGIPASS deployment should be done in accordance with only the following described scenarios. Deviating from
these advised scenarios may result in security vulnerabilities (e.g. brute force attacks).
2.6.1. Stand-Alone: RADIUS Attributes from DIGIPASS User Account
In this scenario, IDENTIKEY Authentication Server retrieves RADIUS attributes from the DIGIPASS user account and
returns them with an Accept message to the RADIUS client.
This scenario can be implemented with the following supported password protocols:
n PAP
n CHAP
n MSCHAP
n MSCHAP2
IDENTIKEY Authentication Server 3.20 – Product Guide 32
2. Overview
Image 18: Stand-alone: RADIUS Attributes from DIGIPASS user account
2.6.2. Stand-alone: No RADIUS Attributes Required
This scenario is identical to 2.6.1. Stand-Alone: RADIUS Attributes from DIGIPASS User Account, except that it does
not use RADIUS attributes to authenticate users.
Image 19: Stand-alone: No RADIUS Attributes Required
IDENTIKEY Authentication Server 3.20 – Product Guide 33
2. Overview
2.6.3. Wireless RADIUS
Using this method, the user only enters their OTP (and PIN, when required). IDENTIKEY Authentication Server has to
learn the static password for the user; as such, when the user gives the correct OTP, IDENTIKEY Authentication
Server can send the static password to the RADIUS server.
The Wireless RADIUS method can be used if one of the supported protocols is used. For a list of supported
RADIUS protocols, refer to 3.9. Supported RADIUS Protocols.
Image 20: IDENTIKEY Authentication Server with Wireless RADIUS
2.6.4. Proxy Target: RADIUS Server Acts as Proxy
In this scenario, a RADIUS server acts as a proxy for authentication, effectively delegating the authentication pro-
cess to IDENTIKEY Authentication Server. The RADIUS server provides the authorization attributes after IDENTIKEY
Authentication Server has accepted the user credentials.
A RADIUS server can forward authentication to IDENTIKEY Authentication Server if:
n The RADIUS server supports the proxying of authentication while returning attributes itself
n The RADIUS server can forward authentication request using one of the supported password protocols (as
listed in Supported password protocols).
IDENTIKEY Authentication Server 3.20 – Product Guide 34
2. Overview
n The RADIUS server supports an access-challenge response from IDENTIKEY Authentication Server, if
required. The access-challenge mechanism is used for challenge/response and Virtual Mobile Authentic-
ator, although it is still possible to use Virtual Mobile Authenticator without that mechanism.
If the RADIUS server is capable, this scenario allows IDENTIKEY Authentication Server to operate in an environment
that uses certificate-based EAP protocols such as PEAP and EAP-TTLS. To make this work, the RADIUS server
decrypts the user credentials into a simpler protocol before forwarding the request to IDENTIKEY Authentication
Server.
Image 21: IDENTIKEY Authentication Server with RADIUS Server Acting as a Proxy
2.6.5. Intermediary: RADIUS Server as Back-End Server
After validating the one-time password, IDENTIKEY Authentication Server forwards requests to a RADIUS server in
order to retrieve authorization attributes. It is necessary to provide a static password to the RADIUS server to
achieve this. There are two methods of implementing this scenario:
Login via OTP only
Using this method, the user only enters their OTP (and PIN, when required). IDENTIKEY Authentication Server
has to learn the static password for the user; this allows IDENTIKEY Authentication Server to send the static
password to the RADIUS server when the user provides the correct OTP.
IDENTIKEY Authentication Server 3.20 – Product Guide 35
2. Overview
Image 22: RADIUS Server as Back-End Server (Users Log In with OTP Only)
This method can be used if:
n One of the supported password protocols is used (as listed in Supported password protocols).
n The static passwords can be 'learnt' by IDENTIKEY Authentication Server.
If the password protocol PAP is used, IDENTIKEY Authentication Server has the ability to learn the static pass-
words automatically. The user then has to perform at least one login with their static password; if the RADIUS
server accepts the password, IDENTIKEY Authentication Server can learn it.
However, if one of the other password protocols is used, this process is not possible. In that case, there are a
few other ways in which the passwords can be learnt, through administrative data entry or using the OneSpan
User Websites.
Login via Password and OTP
Using this method, the user enters a static password and one-time password at each login. IDENTIKEY
Authentication Server validates the OTP; if the OTP is valid, it forwards the static password to the RADIUS
server.
IDENTIKEY Authentication Server 3.20 – Product Guide 36
2. Overview
Image 23: RADIUS Server as Back-End Server (Users Log In with Both Password and OTP)
This method can be used if the PAP password protocol is used. This is because IDENTIKEY Authentication
Server uses both CHAP and MSCHAP to hash the password and OTP together inseparably.
2.7. IDENTIKEY Authentication Server in a Web Environment
2.7.1. SOAP Integration
IDENTIKEY Authentication Server has a SOAP module that can be used to integrate IDENTIKEY Authentication Server
with web applications. The IDENTIKEY Authentication Server SOAP Interface allows the following IDENTIKEY
Authentication Server functions to be integrated into web applications:
n User Authentication
n Signature Validation
n Software DIGIPASS Provisioning
n Administration
n Reporting
IDENTIKEY Authentication Server 3.20 – Product Guide 37
2. Overview
2.7.2. DIGIPASS Authentication for IIS Basic
DIGIPASS Authentication for IIS Basic is an add-on designed for use with Microsoft Internet Information Services
(IIS). It can be configured to intercept authentication requests and redirect them to IDENTIKEY Authentication
Server. DIGIPASS Authentication for IIS Basic verifies the credentials with IDENTIKEY Authentication Server first.
Normally, this means verifying the one-time password. If the OTP is valid, then IDENTIKEY Authentication Server
passes the static password back to IIS as if the user had entered it, and the normal website authentication process
completes the login.
To enable verification via IDENTIKEY Authentication Server, it is necessary to provide a static password (typically
the Windows password) to IIS. There are two methods of implementing this:
Log in with OTP only
Using this method, the user only enters their OTP (and PIN, when required). IDENTIKEY Authentication Server
has to learn the static password for the user, so that when the user gives the correct OTP, it can give the static
password back to IIS.
IDENTIKEY Authentication Server 3.20 – Product Guide 38
2. Overview
Image 24: IDENTIKEY Authentication Server in an IIS Web Environment (OTP-Only)
IDENTIKEY Authentication Server can automatically learn the static Windows passwords. The user has to per-
form at least one login with their static password – if this password is validated by Windows, IDENTIKEY
Authentication Server can learn it.
The same process can also be used if the static passwords are held in a RADIUS server. However, the
IDENTIKEY Authentication Server license must have RADIUS support activated for this to be enabled.
This process is not possible if the static passwords are not Windows or RADIUS passwords. Such passwords
will need to be manually entered.
IDENTIKEY Authentication Server 3.20 – Product Guide 39
2. Overview
Log in with Password and OTP
Using this method, the user enters their static password and OTP at each login. IDENTIKEY Authentication
Server validates the OTP; if valid, IDENTIKEY Authentication Server returns only the static password to IIS.
Image 25: IDENTIKEY Authentication Server in an IIS Web Environment (OTP+Password Login)
This method may be necessary when the static passwords are not Windows passwords, e.g. NetIQ eDirectory
passwords. It also may be suitable if you do not want IDENTIKEY Authentication Server to store your users'
Windows passwords.
Note
IDENTIKEY Authentication Server strongly encrypts Windows passwords whenever it is configured to store them.
IDENTIKEY Authentication Server 3.20 – Product Guide 40
2. Overview
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that to be GDPR-
compliant, the respective DIGIPASS Authentication Modules must have use SSL enabled in the DIGIPASS
Authentication Configuration Center.
If tracing or logging is used, ensure that the folder or disk containing the trace or log files is encrypted.
2.8. IDENTIKEY Authentication Server Administration Components
IDENTIKEY Authentication Server includes several administration components. These components are used for a
wide range of tasks, including (but not limited to) auditing, configuration, and reporting.
Administration Web Interface
The Administration Web Interface is a web-based administration application. The homepage of the Admin-
istration Web Interface provides quick links to managing the DIGIPASS and user settings, and provides inform-
ation on the IDENTIKEY Authentication Server status. This information includes the time, date, and location
(i.e. the IP address) of the last successful administrative log-on of the administrator currently logged in.
The Administration Web Interface is used to complete most of the administration tasks in the IDENTIKEY
Authentication Server environment.
These tasks include:
n Managing user accounts and DIGIPASS
n Defining the organizational structure
n Managing policies
n Creating and running reports
n Managing Client Components
n Configuring selected IDENTIKEY Authentication Server settings
IDENTIKEY Extension for Active Directory Users and Computers
IDENTIKEY Authentication Server also includes an Active Directory Users and Computers Extension. This exten-
sion allows administrators to manage DIGIPASS user account and DIGIPASS records where IDENTIKEY
Authentication Server uses Active Directory as its data store.
Audit System
The IDENTIKEY Authentication Server Audit System tracks operations performed by IDENTIKEY Authentication
Server, including RADIUS accounting information where required. Each operation generates audit messages
that are written to either a text file or a database.
Audit information can be used to generate reports, for example, the number of failed authentications over a
certain period. IDENTIKEY Authentication Server system administrators can also use audit information to mon-
itor system performance, or suspicious activity.
IDENTIKEY Authentication Server 3.20 – Product Guide 41
2. Overview
IDENTIKEY Authentication Server also includes an Audit Viewer, which is used to view audit information. This
utility allows System administrators to filter audit information, making it easier to understand. The Audit
Viewer also allows you to view audit information from different sources.
Using the Audit Viewer to view audit information helps system administrators to troubleshoot effectively, and
helps them monitor significant events in the system.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), ensure that GDPR-compliance
is met when auditing with IDENTIKEY Authentication Server by:
n Encrypting the database and connections to it if database auditing is used.
n Encrypting the folder or disk containing the audit text file if text file auditing is used.
n Encrypting the Windows Event Logs folder (also on remote machines if remote logging is enabled).
n Encrypting the Linux syslog folder (also on remote machine if remote logging is enabled).
For more information about GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regu-
lation Compliance Guide.
Reporting Module
The Reporting Module is part of the Administration Web Interface package. This module contains the tools
required to run a set of standard reports and to create and run custom reports.
Reports may be based on audit data, user account data or DIGIPASS. Formatting templates can be used to
convert the output into the preferred format, using XSLT.
Tcl Command-Line Administration
IDENTIKEY Authentication Server also includes a Tcl extension, which is used for command-line admin-
istration tasks. This extension enables Tool Command Language (Tcl) scripting, which can be used in order to
automate regular administration tasks or perform them in bulk. IDENTIKEY Authentication Server provides a
stand-alone Tcl interpreter to allow Tcl Command-Line Administration in the absence of an existing Tcl envir-
onment.
The Tcl extension uses the IDENTIKEY Authentication Server to manage the data store. This extension uses
the SEAL protocol to communicate with the IDENTIKEY Authentication Server.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that the
dpadmincmd.xml configuration file must be configured to enable the SSL parameter.
For more information on GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regulation
Compliance Guide.
IDENTIKEY Authentication Server 3.20 – Product Guide 42
2. Overview
IDENTIKEY Authentication Server Configuration
IDENTIKEY Authentication Server uses a local XML text file to store certain configuration settings. These set-
tings can be managed using a graphical user interface program.
IDENTIKEY Authentication Server also includes a Maintenance Wizard; this utility is used to carry out certain
maintenance tasks, e.g. changing the IP address of the server.
2.9. IDENTIKEY Authentication Server Data Model
IDENTIKEY Authentication Server can use either of two types of data stores:
n A supported ODBC-compliant database
n Active Directory
The data model will vary slightly depending on which data store is used. The following sections describe the types
of records stored in the IDENTIKEY Authentication Server data store.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), be aware that when selecting
the embedded MariaDB during installation, you will be prompted to choose whether or not to use encryption. By
selecting Yes, IDENTIKEY Authentication Server will use data-at-rest encryption for the database, and use ODBC
connection encryption by default.
When selecting the Advanced installation option and not opting for a MariaDB database, you are responsible for
protecting the database and the connections to it.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that if your organization
chooses to install IDENTIKEY Authentication Server with an Active Directory storage, it is the responsibility of your
organization to protect sensitive data within Active Directory, so that it is compliant with the GDPR.
For more information on GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regulation
Compliance Guide.
2.9.1. DIGIPASS Record
A DIGIPASS record must exist in the data store for each DIGIPASS in use. This record contains:
n Information about the DIGIPASS (i.e. serial number and model)
n The names and programming parameters of Applications in the DIGIPASS
n The status of various options (i.e. DIGIPASS lock)
IDENTIKEY Authentication Server 3.20 – Product Guide 43
2. Overview
Some of the information in this record is encrypted together in what is called the DIGIPASS BLOB. There is one
BLOB per DIGIPASS Application. Each time a one-time password is used (whether or not the authentication is suc-
cessful), IDENTIKEY Authentication Server updates the DIGIPASS BLOB to prevent the one-time password from
being reused.
2.9.2. DIGIPASS user account Record
Each user logging in via DIGIPASS authentication will require a DIGIPASS user account. The DIGIPASS user account
record contains information needed by IDENTIKEY Authentication Server (i.e. authentication settings). A DIGIPASS
must be assigned to a DIGIPASS user account before it can be used for authentication.
In addition, administrative privileges are assigned to DIGIPASS user account. As such, each administrator also
needs a DIGIPASS user account.
2.9.3. Component Record
Component records are created to represent:
n IDENTIKEY Authentication Servers
n Authentication, Signature Validation, and Provisioning Client Components
n Administration Client Components
IDENTIKEY Authentication Server uses component records to determine which requests from which clients can be
processed. Component records also specify which policy should be used when processing requests (see 2.9.4.
Policy Records).
Component records are also used to hold:
n Shared Secrets and Character Encoding for RADIUS clients
n License keys for IDENTIKEY Authentication Server instances and DIGIPASS Authentication Module com-
ponents
2.9.4. Policy Records
A policy record (or policy) specifies various settings that affect request handling processes. Each request is handled
according to a policy that is identified by the applicable component record.
Examples of policy settings include:
n Whether Local and/or Back-End authentication should be used
n Whether various automatic management features should be used
n The DIGIPASS Application types required
n Backup Virtual Mobile Authenticator settings
IDENTIKEY Authentication Server 3.20 – Product Guide 44
2. Overview
2.9.5. Back-End Server Record
A back-end server record is required when IDENTIKEY Authentication Server uses a RADIUS or LDAP server for
authentication. It is possible to create more than one back-end server record, for fail-over purposes. You can also
allocate different back-end servers for different user domains.
2.9.6. Domain Record
Domains form the basis for the organizational structure in an ODBC database. Where IDENTIKEY Authentication
Server uses Active Directory as its data store, the standard Active Directory domains are used instead.
Active Directory
IDENTIKEY Authentication Server operates within the pre-existing Active Directory domain and organizational
unit structure. Each DIGIPASS user and DIGIPASS must belong to a domain in Active Directory. User IDs must
be unique within a domain, but may be repeated between domains.
While DIGIPASS user account and DIGIPASS records can belong to any domain, a single domain is identified
during installation as the DIGIPASS Configuration Domain. This domain is used to store the following records:
n Component
n Policy
n Back-end server
When no domain is specified, the DIGIPASS configuration domain is also used as a default domain for user
lookup.
ODBC Database
With an ODBC database, domains perform the following functions:
n Allow different user groups to be separated
n Provide the ability to limit administrator activities to the administrator's own domain (delegated admin-
istration)
n Allocate unassigned DIGIPASS records to different domains; for example, to mirror the geographic location
of the devices
Each DIGIPASS User and DIGIPASS must belong to a domain. One domain is identified as the Master Domain –
this will be the default domain when none is specified. In addition, administrators in the Master Domain can
be given rights to access data in all domains, while other administrators are limited to data in their own
domain.
User IDs must be unique within a domain, but may be repeated between domains. DIGIPASS serial numbers
must be unique in the database.
IDENTIKEY Authentication Server 3.20 – Product Guide 45
2. Overview
2.9.7. Organizational Unit Record
Like domains, IDENTIKEY Authentication Server handles organizational units differently depending on whether Act-
ive Directory or an ODBC database is used as its data store.
Active Directory
When IDENTIKEY Authentication Server uses Active Directory as its data store, the standard Active Directory
Organizational Units are used instead.
DIGIPASS user accounts and DIGIPASS records are normally stored in organizational units or the users con-
tainer. A special container called DIGIPASS-Pool is created during installation to hold unassigned DIGIPASS,
although they can be located in organizational units instead.
Administration duties may be assigned to administrators per organizational unit, in the same way that regular
user administration is delegated at that level.
ODBC Database
When IDENTIKEY Authentication Server uses an ODBC database as its data store, organizational units allow
further compartmentalization of DIGIPASS user accounts, DIGIPASS records, and administration duties. organ-
izational units are included to:
n Limit the activities of an administrator to their own organizational unit (i.e. delegated administration)
n Allocate unassigned DIGIPASS records to different organizational units; for example, to mirror the geo-
graphic location of the devices
DIGIPASS user accounts and DIGIPASS records may belong to an organizational unit, but this is not mandatory.
2.10. Integrating with IDENTIKEY Authentication Server
The following sections describe the different functions supported by various communicators within IDENTIKEY
Authentication Server. For technical details about integrating with IDENTIKEY Authentication Server, refer to the
IDENTIKEY Authentication Server SDK documentation.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), ensure that the communicator
interfaces are configured to use SSL. If an IDENTIKEY Authentication Server component does not support SSL, the
respective interface must be configured without SSL; however, to be GDPR-compliant, it is advised to set up an
encrypted VPN tunnel to secure the communication. Note that you should always set up an encrypted VPN tunnel
to secure the communication between RADIUS clients and IDENTIKEY Authentication Server.
IDENTIKEY Authentication Server 3.20 – Product Guide 46
2. Overview
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
2.10.1. SOAP interfaces
IDENTIKEY Authentication Server includes SOAP interfaces to support the following functions:
n User Authentication
n Signature Validation
n Software DIGIPASS Provisioning
n Administration
n Reporting
2.10.2. RADIUS
IDENTIKEY Authentication Server also includes RADIUS communicator to support authentication (Access-Requests)
via the following protocols:
n PAP
n CHAP
n MSCHAP
n MSCHAP2
MPPE keys are generated for MSCHAP and MSCHAP2. IDENTIKEY Authentication Server can also handle accounting
requests and return RADIUS attributes for authorization. However, IDENTIKEY Authentication Server does not act as
an authorization server.
An existing RADIUS server may be used as a back-end system to allow any or all of the following:
n Dynamically create DIGIPASS user account
n Verify static passwords
n Retrieve a user's RADIUS attributes
2.10.3. Back-End Integration
There are a number of systems that can be used as IDENTIKEY Authentication Server back ends. These back ends
can be used as an authority on authentication data. For more information, refer to 3.7. Back-End Authentication.
IDENTIKEY Authentication Server 3.20 – Product Guide 47
2. Overview
2.10.4. Custom Back-End Integration
You can write your own plug-in engine to attach IDENTIKEY Authentication Server to your own back end system.
This would be used primarily as an authority to permit dynamic creation of user accounts in IDENTIKEY Authentic-
ation Server and for verification of static passwords.
Note
For Linux installations, a custom back-end engine must have root:root ownership and permissions set to
0755 to allow IDENTIKEY Authentication Server to load it.
2.11. SOAP SSL
Secure Sockets Layer (SSL) is a cryptographic protocol that provides secure communications over the Internet for
e-mail, web browsing, and other types of web protocols. IDENTIKEY Authentication Server uses SSL to secure the
connection between two web-based applications via SOAP.
SSL is the method by which a client can obtain a secure connection to an SSL-enabled server. The SSL-enabled
server can identify itself to the client in a trusted manner before any information is passed between the client and
the SSL-enabled server.
2.11.1. Important SSL-specific terms
Some of the terms used in describing the function of SSL are specific to SSL and cryptography. Listed below are
some of the terms used in this chapter, and what they mean:
Handshake
A procedure by which the client machine and the SSL-enabled server establish a trusted and secure con-
nection before passing any sensitive information to each other.
Certificate
A digitally signed document (either signed by a Certificate Authority or self-signed) used to establish the cre-
dentials of the subject to which the certificate was issued.
Certificate Authority
A trusted third party used to issue the certificates. Each browser will have a list of trusted Certificate Author-
ities it can use to check against the signature on a certificate.
Public Key
A key used to encrypt and decrypt information that is known to the SSL-enabled server and clients that use it.
IDENTIKEY Authentication Server 3.20 – Product Guide 48
2. Overview
Private Key
A key known only to the SSL-enabled server that is used to decrypt information.
Symmetrical Encryption
Encryption that uses only one key to encrypt and decrypt information.
Asymmetric Encryption
Encryption that uses one key to encrypt information, and another to decrypt it.
2.11.2. SSL, SOAP and IDENTIKEY Authentication Server
The server-side of SSL is mandatory in implementing SOAP interfaces for IDENTIKEY Authentication Server. The
SOAP client must utilize SSL to verify the server when attempting to connect.
When configuring the SOAP Communication Protocol in the Configuration Utility, you can specify whether the client
certificate is any of the following:
n Never
n Required
n Optional
n Required - Signed Address Only: The client certificate must include the IP address of the client. The server
will check the IP address from the client certificate against the client it is establishing a connection with,
and the handshake will fail if the two IP addresses don't match.
The Configuration Wizard can provide a self-signed SSL certificate. This self-signed SSL certificate is time-limited,
so it will expire after a period of time. When the test SSL certificate expires, you can recreate it from the Con-
figuration Wizard. Alternatively, you can also purchase an SSL certificate with a longer expiry period.
Note
The Configuration Wizard runs in two modes: Installation Wizard and Maintenance Wizard. For more information,
refer to 9.8. Configuration Wizard.
In the Configuration Utility, the SOAP Communication protocol page also contains a Re-Verify on Re-Negotiation
checkbox. Tick this box to force the connection between SOAP and the IDENTIKEY Authentication Server to be re-
verified each time a connection is established.
Warning
Enabling the Re-Verify on Re-Negotiation option may incur a performance penalty. As such, do not do so unless
absolutely necessary.
IDENTIKEY Authentication Server 3.20 – Product Guide 49
2. Overview
2.12. PCI-DSS compliance
IDENTIKEY Authentication Server contains features which support the following PCI-DSS compliance requirements:
n Cryptographic Key Rotations
n Performance Monitoring
n PAN number not available/displayed in the clear
n Enhanced security for replicated data – SEAL over SSL
n OWASP testing
n Unused user account check
n Report to show inactive DIGIPASS
n Password management – imposing high strength passwords for administrator passwords
n Secure Auditing
2.13. Maker–Checker Authorization
If maker–checker authorization is enabled, certain operations initiated by one administrator (maker) can only be
executed after approval and authorization by another administrator (checker).
The so-called maker–checker authorization is an optional feature that can be enabled/disabled in the IDENTIKEY
Authentication Server Administration Web Interface to provide an additional layer of authorization. By enabling this
feature, the setting is replicated system-wide over all IDENTIKEY Authentication Server instances.
The maker–checker feature introduces the four-eyes principle, in which the authorization process requires two dif-
ferent individuals to complete an administrative operation, when:
n Creating a user
n Deleting a user
n Assigning a DIGIPASS authenticator
n Unassigning a DIGIPASS authenticator
IDENTIKEY Authentication Server 3.20 – Product Guide 50
2. Overview
Image 26: Maker–Checker Authorization Workflow
In the IDENTIKEY Authentication Server Administration Web Interface, the maker administrator selects the oper-
ation that needs approval and designates a checker administrator. The system sends a notification via e-mail (noti-
fication messages are customizable) to the checker administrator that there is a pending administrative operation.
In case of approval, the maker administrator receives notification that the operation has been authorized and is
ready for execution.
Note
Administrators, other than the designated checker, can approve/reject pending operations, if they either have
master administrator privileges with Access Data in All Domains assigned to them, or if they have administrative
privileges within their respective domains or organizational units.
2.13.1. Things to Consider When Using Maker–Checker Authorization
Whereas unassigning a DIGIPASS authenticator is protected by maker– checker authorization, deleting a
DIGIPASS authenticator is currently not. However, when deleting a DIGIPASS authenticator the respective device is
implicitly unassigned before it is deleted from the datastore—the unassignment operation in this case is not sub-
ject to maker–checker authorization. This special case allows bypassing maker–checker authorization.
Warning
An administrator can circumvent maker–checker authorization for unassigning a DIGIPASS authenticator, by just
deleting the device.
To prevent this, do not assign the Delete DIGIPASS privilege to administrators, who have also the Unassign
DIGIPASS privilege assigned and are supposed to unassign DIGIPASS authenticators in a controlled environment
with maker–checker authorization enabled.
IDENTIKEY Authentication Server 3.20 – Product Guide 51
2. Overview
2.13.2. Limitations of Maker-Checker Authorization
The following section lists the limitations of the maker–checker authorization feature in IDENTIKEY Authentication
Server.
The maker–checker authorization feature is limited to:
n ODBC data storage only
The following actions/tools are not supported when maker–checker authorization is enabled:
n LDAP Synchronization Tool
n DIGIPASS autoassign
IDENTIKEY Authentication Server 3.20 – Product Guide 52
3. User Authentication
3. User Authentication
This section describes the different processes involved in the way IDENTIKEY Authentication Server authenticates
users.
3.1. IDENTIKEY Authentication Server Authentication Process
IDENTIKEY Authentication Server authenticates logins via two methods:
n Local authentication: IDENTIKEY Authentication Server uses information from its own data store
n Back-end authentication: IDENTIKEY Authentication Server consults a back-end system to verify login
information
The exact authentication process used by IDENTIKEY Authentication Server will vary depending on the applicable
policy and the DIGIPASS user account.
The following process overview describes how IDENTIKEY Authentication Server authenticates DIGIPASS users:
1. Verify that a client component record for the client application sending the authentication request exists in
the data store (see 3.3. Identifying the Component Record).
2. Determine which policy applies for the client component record (see 3.4. Identifying a Policy).
3. Perform several user checks (see 3.5. Looking Up and Checking the DIGIPASS User Account):
n Windows username/domain resolution (if used)
n Existence of a DIGIPASS user account
n Status of DIGIPASS user account (disabled, locked, expired, possible unlock)
4. Local authentication: If local authentication is used, authentication can occur in two ways (see 3.6. Local
Authentication):
n With a DIGIPASS authenticator: Verify a one-time password (OTP), Challenge/Response, or Virtual
Mobile Authenticator login.
n Without a DIGIPASS authenticator: Verify a static password.
5. back-end authentication: Check the provided password with another back-end system (see 3.7. Back-
End Authentication).
6. (OPTIONAL) If a Challenge/Response or Virtual Mobile Authenticator login is needed, provide a challenge or
OTP.
7. Audit and return the authentication result.
During the last step of the authentication process, IDENTIKEY Authentication Server may perform relevant database
updates, e.g. DIGIPASS user account lock.
3.2. Logging in with a DIGIPASS
The following table illustrates the typical login process for the three basic login methods supported by IDENTIKEY
Authentication Server.
IDENTIKEY Authentication Server 3.20 – Product Guide 53
3. User Authentication
Table 1: Login methods
Response-Only Challenge/Response Virtual Mobile Authenticator
1. User enters user ID and one- 1. User enters user ID and pass- 1. User enters user ID and password/keyword.
time password. word/keyword. 2. User clicks OK to request a Virtual Mobile
2. User clicks OK to attempt a 2. User clicks OK to request a Authenticator login.
login. challenge/response login. 3. Authentication Server verifies if user is
3. Authentication Server 3. Authentication Server gen- allowed to use Virtual Mobile Authenticator.
authenticates user. erates a challenge. 4. Authentication Server generates an OTP and
4. User enters the challenge into sends it to the user.
DIGIPASS. 5. User receives the OTP (i.e. via SMS).
5. DIGIPASS generates an 6. User enters the password/keyword and
OTP from the supplied chal- OTP into the login window.
lenge. 7. User clicks OK to attempt a login.
6. User enters the OTP into the 8. Authentication Server authenticates user.
login window.
7. User clicks on OK to attempt a
login.
8. Authentication Server authen-
ticates user.
3.3. Identifying the Component Record
IDENTIKEY Authentication Server identifies a component requesting authentication by using:
Component Type
A name provided by the SOAP application, or a fixed name such as RADIUS Client, Citrix Web Interface ,
Outlook Web Access or Administration Program.
Location
The source IP address of the request.
Note
A client component with an IP address range (IPv4 CIDR notation) as component location will be used to handle
requests from any client within that IP address range. If two (or more) matching client components with over-
lapping IP address ranges are found, the client component with the smaller IP address range (more specific)
takes precedence and will be used to serve the request.
The processes for looking up and verifying a component varies according to the type of component, as outlined in
3.3.1. RADIUS Client Component Check and 3.3.2. DIGIPASS Authentication Module Component Check.
IDENTIKEY Authentication Server 3.20 – Product Guide 54
3. User Authentication
3.3.1. RADIUS Client Component Check
For a RADIUS client, the following component checks are made:
Component Record exists
A component record for the RADIUS client must exist, otherwise the request is discarded without responding:
n Type = RADIUS Client
n Location = the source IP address of the request OR, if there is no RADIUS client at the specified location,
Location = default
Shared Secret is set
The component record must have a shared secret value set, otherwise the request is discarded without
responding.
Any RADIUS client which does not have an explicit component record will be handled using the default RADIUS cli-
ent component if it exists.
3.3.2. DIGIPASS Authentication Module Component Check
For a DIGIPASS Authentication Module component, IDENTIKEY Authentication Server checks whether a com-
ponent record for the DIGIPASS Authentication Module exists; if not, the request is discarded without respond-
ing:
n Type = one of the DIGIPASS Authentication Module component types
n Location = the source IP address of the request
3.4. Identifying a Policy
Policies specify various settings that affect all request handling processes. Each request is handled according to a
policy, which is identified by the applicable client record. For more information, see 13. Policies.
Note
Policies can also be assigned to server components. However, this feature is not relevant for the authentication
process.
For a full listing of possible policy settings and the preloaded policies available with the IDENTIKEY Authentication
Server, refer to the IDENTIKEY Authentication Server Administrator Reference.
IDENTIKEY Authentication Server 3.20 – Product Guide 55
3. User Authentication
3.5. Looking Up and Checking the DIGIPASS User Account
IDENTIKEY Authentication Server performs a number of checks before proceeding to local authentication.
3.5.1. User ID and domain resolution
To allow users to authenticate with user names in different formats, IDENTIKEY Authentication Server identifies
DIGIPASS user accounts via user ID and domain. User ID and domain resolution is processed differently, depending
on the data store IDENTIKEY Authentication Server uses; for illustrations of each process, refer to Image 27: Name
resolution with ODBC database, Image 28: Name resolution with ODBC database and Active Directory back end,
and Image 29: Name resolution with Active Directory storage.
Table 2: User name resolution in IDENTIKEY Authentication Server provides an overview of the user name res-
olution features; for a description of each user name resolution method and DIGIPASS user account identification,
refer to:
n 3.5.1.1. Windows User Name Resolution
n 3.5.1.2. Active Directory User Name Resolution
n 3.5.1.3. Simple User Name Resolution
Table 2: User name resolution in IDENTIKEY Authentication Server
Feature Windows User Active Directory Simple User
Name Res- User Name Res- Name Res-
olution olution olution
User can authenticate with UPN and SAM account name, even if different. ü ü
User can authenticate with UPN that includes alternative UPN domain suffixes. ü ü ü
Supported where IDENTIKEY Authentication Server is installed on a Windows machine ü ü ü
which is a member server of the Windows domain.
Supported where the machine on which IDENTIKEY Authentication Server is installed is ü ü
either not a member server of the Windows domain, or running a Linux operating sys-
tem.
Support for Active Directory users. ü ü ü
Support for Active Directory or Global Catalog as back end. ü ü ü
Resolves user name to SAM account name and FQDN. ü ü
Requires additional configuration of back-end directory information ü ü
IDENTIKEY Authentication Server 3.20 – Product Guide 56
3. User Authentication
Image 27: Name resolution with ODBC database
IDENTIKEY Authentication Server 3.20 – Product Guide 57
3. User Authentication
Image 28: Name resolution with ODBC database and Active Directory back end
IDENTIKEY Authentication Server 3.20 – Product Guide 58
3. User Authentication
Image 29: Name resolution with Active Directory storage
IDENTIKEY Authentication Server 3.20 – Product Guide 59
3. User Authentication
3.5.1.1. Windows User Name Resolution
For the authentication of Active Directory users, there are a few ways to provide user ID and domain details when
logging in:
n NT4-style domain qualification in front of the SAM account name: DOMAIN\userid
n User Principal Name (UPN), e.g. userid@domain
n UPN with domain suffix, e.g. [email protected]
n With separate user ID and domain fields (not possible when using RADIUS)
When DIGIPASS user accounts correspond to Windows user accounts, the Windows User Name Resolution feature
can be used to support these login formats. Windows User Name Resolution should be used where IDENTIKEY
Authentication Server is installed on a Windows machine which is a member server of the Windows domain. Win-
dows User Name Resolution is always used with Active Directory as the data store.
With an ODBC database as the data store, using Windows User Name Resolution is optional. However, if the Win-
dows User Name Resolution process is enabled and fails, the login is rejected. Therefore, a login with a user ID
that does not correspond to a Windows user account will be rejected. A special case in this context are logins
where the user name does not contain a domain. In this case, Windows User Name Resolution is skipped, and the
default domain is used for this login attempt. For more information about default domains, see 3.5.1.5. Default
Domain
With Windows User Name Resolution enabled, Windows resolves the NT4-style and UPN user ID formats to the
SAM account name and the FQDN. You can enable Windows User Name Resolution in the back-end server settings
in IDENTIKEY Authentication Server Administration Web Interface.
3.5.1.2. Active Directory User Name Resolution
For the authentication of Active Directory users, there are a few ways to provide user ID and domain details when
logging in:
n NT4- style domain qualification in front of the SAM account name: DOMAIN\userid
(This login format requires the creation of an alternative domain suffix in the Administration Web Interface.
For more information about domain suffixes, refer to 3.5.1.4. Alternative UPN Suffixes)
n User Principal Name (UPN) e.g. userid@domain
n UPN with domain suffix - e.g. [email protected].
(This login format requires the creation of an alternative domain suffix in the Administration Web Interface.
For more information about domain suffixes, refer to 3.5.1.4. Alternative UPN Suffixes)
When DIGIPASS user accounts correspond to Windows user accounts, the Active Directory User Name Resolution
feature can be used to support these login formats. This feature is a platform-independent alternative to Windows
User Name Resolution for Active Directory users; it may be used where the machine on which IDENTIKEY Authentic-
ation Server is installed is either not a member server of the Windows domain, or running a Linux operating sys-
tem.
UPN and SAM account name will be translated for Active Directory users. The following prerequisites for using this
feature apply:
IDENTIKEY Authentication Server 3.20 – Product Guide 60
3. User Authentication
n Active Directory User Name Resolution is enabled
n Windows User Name Resolution is disabled (or does not exist)
n The back end is Active Directory or Global Catalog
n An ODBC database is used as data store
3.5.1.3. Simple User Name Resolution
On deployments with an ODBC database, when Windows User Name Resolution is not used, the following formats
are available for verifying a user ID and domain:
n Using a similar format to UPN: user@domain, sam@fqdn
n With separate user ID and domain fields
If the user@domain format is used for the user ID, IDENTIKEY Authentication Server will look for a domain
record with the name given after the @. If the domain is found, the @domain part will be stripped from the user
ID before the authentication process continues.
If a domain is not found, the user ID will be left as user@domain, and no domain will be identified. In that case,
the Default Domain processing will be used, as described in 3.5.1.5. Default Domain.
3.5.1.4. Alternative UPN Suffixes
To provide additional logon security and simplify user names, you can provide alternative UPN suffixes in the
UPN Suffixes tab. Alternative UPN suffixes allow users to authenticate with their User Principal Name (UPN), even if
it contains an alternative domain suffix. In addition, you can provide an NT4-style domain as an alternative suffix,
which is required for the name resolution of NT4-style user names with Active Directory User Name Resolution or
Simple User Name Resolution.
This is an alternative to Windows User Name translation on Windows and is also supported on Linux. Alternative
UPN suffixes are not supported on IDENTIKEY Authentication Server configurations that use Active Directory as stor-
age.
3.5.1.5. Default Domain
In some cases, only a user ID is supplied for authentication. When this occurs, it is still necessary to identify a cor-
responding domain in order to look up the DIGIPASS user account; for this purpose, a default domain is used.
The default domain can be configured in the following ways:
n The default domain can be configured in the policy record. In this case, the default domain will be used
when no domain has been identified.
n When the policy has no default domain set, the Master Domain will be used.
3.5.1.6. Active Directory Storage
When Active Directory is used as the data store, a user account in IDENTIKEY Authentication Server is always
attached to an Active Directory user account. Therefore, if an authentication request is received for a user who
does not have an account in Active Directory, the request is rejected. This is not mandatory for ODBC databases.
IDENTIKEY Authentication Server 3.20 – Product Guide 61
3. User Authentication
3.5.2. Windows Group Check
IDENTIKEY Authentication Server can use specific Windows Groups for authentication when all users are Windows
accounts. This Windows Group Check feature is optional, and might be useful in the following scenarios:
n DIGIPASS is deployed in stages. Users are not required to log in using a DIGIPASS until they are put into a
Windows group. Users can be placed into the group in manageable stages.
n Two-factor authentication is needed only for access to sensitive data, and access is granted to a specific
group of users (eg. administrators). This group of users will require DIGIPASS, and will be authenticated by
IDENTIKEY Authentication Server. Other users will be authenticated by another authentication method.
n Most users will have DIGIPASS and be permitted to log in to the system, but some users should not be
authenticated under any circumstances.
n Authentication is needed for the live Audit Viewer connection to IDENTIKEY Authentication Server (i.e.
when using Active Directory as the data store). The Group Check can be used to limit which users are
allowed to connect, for example, to the Domain Admins group.
Nested Groups
IDENTIKEY Authentication Server supports nested groups for Windows Group Check in the context of Active Dir-
ectory. For more information on nested groups, refer to the Microsoft documentation.
Warning
Enabling Nested Groups may cause performance issues in IDENTIKEY Authentication Server, due to:
n Too many groups in one domain
n Active Directory not optimally configured. Refer to the Microsoft documentation for more information.
When Windows Group Check is active, users who are in one of the defined groups go through the full authen-
tication process. However, there are a few Group Check Modes that control the outcome for users who are not in
one of the groups. The Group Check Mode is defined in the policy.
One or more Windows Groups must be defined in the Windows Group List in the relevant policy. The list items can
be searched and edited , groups can be added and removed as required. Group membership is checked within the
user's own domain only; these groups must exist in each domain where there are users who need to be included
in a group.
Note
When Windows Group Check is used, the login will fail if the group check fails. This will occur for a user who is
unknown to Windows.
The following Group Check modes are available:
IDENTIKEY Authentication Server 3.20 – Product Guide 62
3. User Authentication
3.5.2.1. 'Pass Back' Mode
The policy property sheet defines this mode as Pass requests for users not in listed groups back to host system. In
this mode,IDENTIKEY Authentication Server will not handle authentication for users who are not in one of the lis-
ted/defined groups; instead, these users are handled by the host system (eg. IIS).
In effect, this means that such users do not need DIGIPASS user accounts, and they do not need to use a DIGIPASS
to log on. As soon as the group check indicates that the user is not to be handled, IDENTIKEY Authentication Server
stops authentication processing stops and returns a not handled result.
Pass back mode is suitable for staged deployment of DIGIPASS, and for cases where only certain users need strong
(DIGIPASS) authentication.
3.5.2.2. Reject mode
The policy property sheet defines this mode as Reject requests for users not in listed groups. In this mode,
IDENTIKEY Authentication Server rejects authentication immediately for users who are not in one of the defined / lis-
ted groups.
This mode is suitable for restricting which users are permitted to log in.
3.5.2.3. Back-end mode
The policy property sheet defines this mode as Use only Back-End Authentication for users not in listed groups.
This mode can be used if back-end authentication is set up. For more information, refer to 3.7. Back-End
Authentication.
In this mode, IDENTIKEY Authentication Server will only use back-end authentication for users who are not in any
defined/listed groups.
Example
If RADIUS back-end authentication is used, the job of authenticating users not in the defined/listed groups is del-
egated to the RADIUS server. No lookup will be carried out for the DIGIPASS user account, and no further local
authentication will be carried out.
back-end authentication will be used for the out-of-group users, even if the policy setting for back-end authen-
tication is set to None. With such a policy setting, the in-group users would be authenticated only by local authen-
tication, while the out-of-group users would be authenticated only by back-end authentication. However, it is
necessary to define the Back-End Protocol Policy setting.
This mode is suitable for staged deployment of DIGIPASS, and for cases where only certain users need strong
(DIGIPASS) authentication.
IDENTIKEY Authentication Server 3.20 – Product Guide 63
3. User Authentication
3.5.3. Accepted Domain
If configured, only users who are member of an accepted domain are allowed to log in. Accepted domains are
defined on the component policy (see 3.3. Identifying the Component Record). The user domain is compared to
the defined accepted domain, and if they do not match access is denied. This can be used in conjunction with the
default domain (see 3.5.1.5. Default Domain).
For more information about how domains are resolved, see 3.5.1. User ID and domain resolution.
3.5.4. Look up a DIGIPASS User Account
IDENTIKEY Authentication Server verifies that a DIGIPASS user account for the user attempting to log in exists in the
data store. The user ID and domain resolution performed earlier determines the search criteria to look up the
DIGIPASS user account.
If a DIGIPASS user account is found, the account status is verified (see 3.5.6. Verify DIGIPASS User Account Status).
If no DIGIPASS user account is found, then policy settings will determine whether IDENTIKEY Authentication Server
continues processing the authentication request or rejects it:
n If local authentication is required, a DIGIPASS user account must exist. It is only possible to proceed if the
Dynamic User Registration feature is enabled (see 3.5.5. Dynamic User Registration).
n If local authentication is not required, authentication processing can proceed without a DIGIPASS user
account.
If the Local Authentication Policy setting is None, local authentication is not required. If it is set to DIGIPASS/Pass-
word during Grace Period, DIGIPASS or Password, or Digipass Only, local authentication is required.
3.5.5. Dynamic User Registration
Dynamic User Registration (DUR) allows to create a DIGIPASS user account automatically when the user credentials
are validated using back-end authentication. The correct static password is sufficient to permit a DIGIPASS user
account to be created. DUR saves the administrative work of manually creating or importing DIGIPASS user
accounts.
DUR is typically used in conjunction with the following features:
n Auto-Assignment, where IDENTIKEY Authentication Server will select a random DIGIPASS authenticator and
assign it to the new DIGIPASS user account as it is created, or
n Self-Assignment, which will allow the new user to assign a DIGIPASS to their account as part of their login
process.
IDENTIKEY Authentication Server 3.20 – Product Guide 64
3. User Authentication
Note
When maker–checker authorization is enabled, assigning a DIGIPASS authenticator requires the approval of a
checker administrator. In that case, Auto-Assignment is not available.
For more information about DIGIPASS assignment features, see 11. DIGIPASS.
In order to control the creation of new accounts, DUR can be used with the following features:
n Windows Name Resolution (mandatory for Active Directory)- this will prevent more than one DIGIPASS user
account being created for the same Windows user account, when they use different user ID formats to log
in.
n Windows Group Check , so that a staged creation of DIGIPASS user accounts and assignment of
DIGIPASS authenticator is achieved.
A typical DUR process using Auto-Assignment and Windows Group Check is illustrated below.
IDENTIKEY Authentication Server 3.20 – Product Guide 65
3. User Authentication
Image 30: Dynamic User Registration (Process)
IDENTIKEY Authentication Server 3.20 – Product Guide 66
3. User Authentication
3.5.6. Verify DIGIPASS User Account Status
IDENTIKEY Authentication Server verifies the status of the DIGIPASS user account found for the user attempting to
log in.
1. If the DIGIPASS user account is disabled, the authentication request is rejected.
2. If the DIGIPASS user account has expired because a specified expiration date has passed, the authen-
tication request is rejected.
3. If the DIGIPASS user account has been suspended due to inactivity, the authentication request is rejected.
IDENTIKEY Authentication Server can be configured to force a DIGIPASS user account to be suspended if it
is not used for a specified amount of time. The number of days that a DIGIPASS user account can remain
unused before being suspended can be configured in the policy used to log in. This value will be checked
and the number of days since the last login will be calculated. If the DIGIPASS user account has been
unused for too long, login will be denied.
4. If the DIGIPASS user account is locked, IDENTIKEY Authentication Server verifies whether a user auto-
unlock attempt is possible (see 10.5. DIGIPASS User Account Auto-Unlock).
If any unlock retries are left and the calculated lock duration since the last authentication request has
elapsed, IDENTIKEY Authentication Server assumes a possible user auto-unlock attempt and allows the
authentication request.
3.6. Local Authentication
Local authentication is a term used to describe the IDENTIKEY Authentication Server authenticating a user based
on information in its data store. Typically the DIGIPASS one-time password is required, but in other cases a static
password may be sufficient.
The Local Authentication Policy setting indicates whether to perform local authentication, and if so, whether a
static password is permitted. This setting is overridden by the same setting in the DIGIPASS user account, unless
that has the value Default. However, this setting in the DIGIPASS user account would typically be used only for rare
special case users.
Note
The Local Authentication policy setting is relevant in the context of software DIGIPASS provisioning. For more
information, see 5. Software DIGIPASS Provisioning.
Using the Windows Group Check in Back-End mode, this setting can be overridden. If a user is not in the list of
groups, no local authentication will be performed.
The possible values for the local authentication setting are as follows:
IDENTIKEY Authentication Server 3.20 – Product Guide 67
3. User Authentication
Default
Local authentication is handled as configured in settings inherited from the parent policy. For more inform-
ation about policies, refer to 13. Policies.
None
No local authentication will take place.
DIGIPASS/ Password during Grace Period
A DIGIPASS one-time password or static password may be verified. The user can authenticate with their static
password until they start to use a DIGIPASS authenticator. The grace period of the authenticator expires the
first time an OTP is used to log in (if it has not been set manually to expire prior to that). After the grace period
has expired, the user can only authenticate with their DIGIPASS authenticator.
DIGIPASS or Password
This authentication mode allows users to permanently use their static password or their
DIGIPASS authenticator, even after the grace period has expired and/or they have previously already used
their authenticator for authentication. In the context of the authentication scenario, use of this authentication
mode is subject to licensing. For provisioning, this authentication mode is license-free.
DIGIPASS Only
A DIGIPASS one-time password must be verified. Users without DIGIPASS will not be able to log in. However,
Self-Assignment is still possible, as an OTP is used as part of the process.
Note
It is also possible to configure user-specific policy settings local authentication. These settings will override those
set by the parent policy. For more information, refer to 13.2. User-Specific Authentication Policy Overrides.
3.6.1. DIGIPASS Lookup
The first step of local authentication is to search for DIGIPASS records applicable to the login. Normally, this is a
simple search for all DIGIPASS assigned to the DIGIPASS user account. However, there are exceptions:
3.6.1.1. No DIGIPASS user account
If there is no DIGIPASS user account, no search will be done. This can occur if Dynamic User Registration is
enabled.
3.6.1.2. Policy Restrictions
The policy can specify restrictions on which types of DIGIPASS and/or DIGIPASS applications may be used. Any com-
bination of the following restrictions can be defined:
IDENTIKEY Authentication Server 3.20 – Product Guide 68
3. User Authentication
Application Names
This refer to a list of named applications. Only DIGIPASS that have one or more of the named applications will
be usable.
Application Type
This can be either Response-Only, Challenge/Response or Multi-Mode. If application Type is set to Response-
Only or Challenge/Response, only DIGIPASS with that application type will be usable. With Multi-Mode, all
application types will match.
DIGIPASS Type
This is a list of models, such as DPGO3, DIGIPASS 260. Only DIGIPASS from the listed models will be
usable. For a more extensive list of DIGIPASS models, refer to 2.3.1. Hardware DIGIPASS authenticator.
Therefore, it is possible that a DIGIPASS user account that has a DIGIPASS assigned will not be able to use that
DIGIPASS to log in, when a certain policy applies. Such a user will be regarded as without a DIGIPASS in that case.
In a different kind of login, a different policy may apply, with no restrictions. In that case, the same user would be
regarded as with a DIGIPASS.
Example
A company has GO 3 DIGIPASS (DPGO3) and Primary Virtual Mobile Authenticator (DPVTL). The Outlook Web
Access login permits both, so its policy does not restrict DIGIPASS Types. However the RADIUS VPN login requires
the Go 3, so its policy specifies DIGIPASS Type = DPGO3.
3.6.1.3. Linked DIGIPASS user account
If a person has multiple DIGIPASS user account (e.g. an administrative account and a normal user account), those
accounts can be linked together. This provides the ability for the two accounts to share a DIGIPASS. In this case,
the DIGIPASS is assigned to one of the accounts, then the other account is linked to it.
When an authenticating DIGIPASS user account is linked to another, the search for DIGIPASS will be done for the
other account.
Note
The linked DIGIPASS user account feature supports Response-Only and Challenge/Response authentication,
Authentication Signature, Push Notification Authentication, and Push Notification Transaction Data Signing.
Example
DIGIPASS user account 2 is linked to DIGIPASS user account 1. The DIGIPASS is assigned to DIGIPASS user account
1. When DIGIPASS user account 1 logs in, the DIGIPASS search is for that account. When DIGIPASS user account 2
logs in however, the DIGIPASS search is for DIGIPASS user account 1.
IDENTIKEY Authentication Server 3.20 – Product Guide 69
3. User Authentication
3.6.2. Authentication with DIGIPASS
When the DIGIPASS lookup returns at least one DIGIPASS record, authentication processing requires a valid one-
time password to succeed, unless:
n All DIGIPASS found are within a grace period.
n The user successfully requests a challenge for Challenge/Response (see below).
n The user successfully requests a Virtual Mobile Authenticator one-time password (see below).
3.6.2.1. Server PIN
A Server PIN may be required in addition to the one-time password; the Server PIN can be used together with the
OTP generated by the DIGIPASS authenticator as part of the online authentication process. The Server PIN is a digit-
based secret, entered by the user during login with the OTP instead of a DIGIPASS PIN, which is entered into the
DIGIPASS authenticator- refer to Section 11.5.1.1. DIGIPASS Client PIN for more information. The entered Server PIN
and OTP are checked by the authenticating server, and server only permits verification of the OTP if submitted with
a valid Server PIN. The additional Server PIN thus provides an extra layer of security, a two-factor security solution.
To authenticate, the user needs to have a connection to the authenticating server, know the Server PIN (something
you know), and to be in possession of the DIGIPASS device (something you have) to generate an OTP.
In some cases a new Server PIN may need to be set. A user's Server PIN can be reset either manually by an
IDENTIKEY Authentication Server administrator, or in the course of assigning a DIGIPASS authenticator. When using
the DIGIPASS Self-Assignment or Auto-Assignment feature of IDENTIKEY Authentication Server, the user can reset
their Server PIN. When the Assignment Mode is set to Self-Assignment-Pin-Reset or Auto-Assignment-Pin-Reset,
the user's Server PIN is automatically reset. This is an optional feature and does not require any administrator
action, once the option has been enabled in the DIGIPASS properties and/or the relevant policy settings have been
set accordingly.
The following permutations of OTP and Server PIN are possible:
n OTP: the normal login where a Server PIN is not required.
n PINOTP: the normal login where a Server PIN is required and is entered before the OTP.
n PINOTPnewpinnewpin: to change the Server PIN, the new PIN is put twice after the OTP.
n OTPnewpinnewpin: to set the Server PIN on first use, when no initial PIN was programmed, the new PIN is
entered twice after the OTP. This is also necessary after an administrative PIN reset.
Server PIN run-time information is provided through the Administration Web Interface by selecting a specific
DIGIPASS record (see Table 3: Server Settings Regulating Server PINs).
Table 3: Server Settings Regulating Server PINs
Setting Explanation
PIN Supported Factory default built-in technology - controls whether a PIN must be included
in a user's login. (Only active if PIN Enabled setting is active.)
PIN Enabled Factory default setting forcing a Server PIN to be used for login. (Only possible
if PIN Supported setting is active.)
IDENTIKEY Authentication Server 3.20 – Product Guide 70
3. User Authentication
Table 3: Server Settings Regulating Server PINs (continued)
Setting Explanation
PIN Change On Enables a user to change their Server PIN for this DIGIPASSdevice.
Force PIN Change Forces the user to change their Server PIN upon next login.
PIN Length The length of the current Server PIN.
PIN Minimum Length The minimum PIN length required by the server.
Server PIN States
The following diagram illustrates the different Server PIN states and which user/administrator actions result in each
one:
IDENTIKEY Authentication Server 3.20 – Product Guide 71
3. User Authentication
Image 31: Server PIN States and Actions
When a server is in the PIN SET CHANGE FORCED state, its corresponding user is forced to change PINs upon login.
Once the user changes the PIN (user action <PIN><OTP><NewPIN><NewPIN>), the server state changes to PIN
SET.
For more information on other user and administrator actions that affect Server PIN states, refer to Section 11.3.
DIGIPASS Record Functions.
IDENTIKEY Authentication Server 3.20 – Product Guide 72
3. User Authentication
3.6.2.2. Grace Period
Each DIGIPASS authenticator may be given a Grace Period when it is assigned to a DIGIPASS user account. This is
the default period (in days) between Auto-Assignment of a DIGIPASS authenticator and the date for users to start
using their authenticator to log in (if applicable). The grace period allows some time for users to continue using
their static password before they receive the DIGIPASS authenticator and learn how to use it. The grace period auto-
matically expires the first time an OTP is used to log in, i.e. after the OTP has been successfully validated (if it has
not been set manually to expire prior to that in the relevant policy).
The grace period does not apply when the Local Authentication mode in a policy is set to Digipass Only. When local
authentication in the relevant policy is set to DIGIPASS/Password during Grace Period, the user can authenticate
with their static password until the grace period has expired; after that they can only authenticate with their
DIGIPASS authenticator. When local authentication is set to DIGIPASS or Password, users can choose to use either
their static password or their DIGIPASS authenticator, even if they have already used their DIGIPASS authenticator,
independent of grace period restrictions.
The grace period can be set during manual administrative assignment of DIGIPASS records as well as during Auto-
Assignment. The grace period does not apply to Self- Assignment , because the user must use the
DIGIPASS authenticator to complete the Self-Assignment process.
3.6.2.3. Grace Period and Policy Restrictions
Because an applied policy might restrict which DIGIPASS authenticator can be used during a login, the grace period
for each DIGIPASS authenticator is independent of other DIGIPASS authenticators. This means that if a user is
assigned two DIGIPASS authenticators, each with a grace period of seven days, the user may log in using one
DIGIPASS within the seven-day period (ending the grace period for that DIGIPASS) without affecting the grace
period for the other DIGIPASS.
Example
The company has set up policies which require a Response-Only login via the local area network, and a Chal-
lenge/Response login via the internet; limited to certain employees. The local authentication mode is set to
DIGIPASS/Password during Grace Period.
Jane has two DIGIPASS authenticators assigned to her – a DIGIPASS 300 with the Challenge/Response applic-
ation enabled, and a DIGIPASS GO 3 with a Response-Only application. The DIGIPASS authenticators are both
assigned to her on Tuesday. Jane receives her DIGIPASS GO 3 on Friday, and immediately uses an OTP to login.
The grace period for her DIGIPASS GO 3 authenticator ends at that time – as of now she must use the DIGIPASS
GO 3 when logging into the intranet from the LAN.
Over the weekend, Jane needs to access the company intranet from home. Because a Challenge/Response
login is required via the internet and she does not yet have her DIGIPASS 300 authenticator, she uses only her
user ID and static password to log in. As she is still within the grace period for her DIGIPASS 300, the login is valid.
During the grace period, if OTP validation fails, the static password is checked. For more information on the static
password check during an authentication attempt, see Section 3.7. Back-End Authentication If the static password
IDENTIKEY Authentication Server 3.20 – Product Guide 73
3. User Authentication
is valid, local authentication succeeds. However, the overall login can still fail if back-end authentication is
enabled.
The password is compared against the DIGIPASS user account's password value. However, if the DIGIPASS user
account does not have a password set, the password has to be verified with back-end authentication. With back-
end authentication disabled and without a password in the DIGIPASS user account, grace period password logins
will not work.
If the passwords do not match and back-end authenticationis enabled, the password will be verified with back-
end authentication.
3.6.2.4. Challenge Generation
There are two modes of generating a challenge for Challenge/Response DIGIPASS applications:
2-Step Challenge/Response
n This mode can be used for Web authentication, where Challenge/Response is supported. In this mode,
the authentication process takes place in two steps.
First, the user requests a challenge to be generated for them. The following policy settings define how this request
should be made:
n Request Method
n Request Keyword.
The challenge is generated specifically for their DIGIPASS and in accordance to the specified settings. For more
information about these settings, refer to 3.6.2.9. Request Method and Keyword.
Assuming that the request for the challenge is accepted and a challenge is returned, the user submits a second
step login with the response to the challenge as their OTP. This second step goes through the whole authen-
tication process again to verify the response.
1-Step Challenge/Response
This mode is also possible for Web authentication, where Challenge/Response is supported. In this mode, the user
sees only one logon step. This mode is suitable for time-based Challenge/Response, but is less secure for non-
time-based Challenge/Response. If an attacker manages to capture some valid responses, they can repeatedly
request new challenges until one they know comes up again.
In this mode, a random challenge is requested automatically by the Web application and presented to the user on
the login page. A general-purpose challenge is generated, without reference to any particular DIGIPASS' pro-
gramming. The user logs in with their response to the challenge as their OTP.
3.6.2.5. Secure Channel-Based Authentication Process
For authentication transactions via the Secure Channel feature, IDENTIKEY Authentication Server generates a
request message, based on the transaction details provided via the client application or a custom request body,
and delivers it to the client application. The request message is generated by IDENTIKEY Authentication Server
IDENTIKEY Authentication Server 3.20 – Product Guide 74
3. User Authentication
upon the Get Secure Challenge and Get Signing Request commands, and is bound to the
DIGIPASS authenticator selected for the relevant transaction. The client application then generates either a QR
code or a color QR code, which represents this request message, and delivers it to the end user, who scans this
image, using a DIGIPASS authenticator that is compliant with the Secure Channel feature. The
DIGIPASS authenticator generates a response for this request message which the end user enters into the client
application; IDENTIKEY Authentication Server validates this response and returns the result to the client application
which completes the signature authentication process.
3.6.2.6. Push–Notification-Based Authentication Process
Push Notification can be used as an out-of-band (OOB) authentication method employing a push mode to enable
client applications on mobile devices, e.g. Mobile Authenticator, to authenticate a user. The user receives a noti-
fication prompt on the mobile device during the authentication process, and completes the authentication process
by tapping on the device (push and login).
For a typical user authentication process via Push Notification, the user initiates the authentication process by
providing their user ID/domain and a keyword, and enter their static password. The following policy settings spe-
cify how this request should be defined:
n Request Method
n Request Keyword
After receiving the corresponding request from the application server, IDENTIKEY Authentication Server generates
the required push notification message, and communicates this to the Message Delivery Component (MDC). The
MDC sends the Push Notification request to the OneSpan Notification Gateway. The Mobile Authenticator retrieves
the push notification details from DIGIPASS Gateway and requests the user to confirm if they wish to log on to the
specified client application. When the user confirms this and accepts the push–notification-based authentication,
the Mobile Authenticator authenticates against IDENTIKEY Authentication Server via the DIGIPASS Gateway.
IDENTIKEY Authentication Server processes this request, and in case of success returns the authentication to the cli-
ent application; the user is informed via the client application that their authentication has succeeded.
For more information on this feature, refer to the DIGIPASS Push Notification - Getting Started Guide. For more
information on the DIGIPASS Gateway, refer to the DIGIPASS Gateway product documentation; for more information
on the Mobile Authenticator, refer to the Mobile Authenticator and Mobile Authenticator Studio product doc-
umentation.
3.6.2.7. Virtual Mobile Authenticator OTP Generation
Using Virtual Mobile Authenticator, the authentication process takes place in two steps:
First, the user requests an OTP to be generated and delivered to them. The following policy settings define how
this request should be made:
n Request Method
n Request Keyword
n Delivery method (SMS, Email, and/or Voice)
IDENTIKEY Authentication Server 3.20 – Product Guide 75
3. User Authentication
The OTP is then sent to the user's mobile phone number or email address recorded in the DIGIPASS user account.
For more information about Request Method and Request Keyword settings, refer to 3.6.2.9. Request Method and
Keyword.
Backup Virtual Mobile Authenticator have additional available restrictions on usage, to minimize the cost of usage.
These are verified before an OTP will be generated. The restrictions are described in 11. DIGIPASS.
Assuming that the request for the OTP is accepted and an OTP is generated and delivered successfully, the user
submits a second step login with the OTP. This second step goes through the whole authentication process again
to verify the OTP.
This process occurs as follows:
1. User requests a Virtual Mobile Authenticator login.
2. IDENTIKEY Authentication Server generates a one-time password.
3. IDENTIKEY Authentication Server sends the one-time password, delivery method, and mobile phone num-
ber or email address to the Message Delivery Component.
4. The Message Delivery Component passes the information to either of the following:
n SMS gateway, which sends a text message containing the one-time password to the user's
mobile phone.
n Mail server, which sends an email containing the one-time password to the user's email address.
n Voice gateway, which sends a text message containing the one-time password to the user's
phone.
5. User receives the one-time password.
6. User enters one-time password into login window.
7. IDENTIKEY Authentication Server authenticates login as usual.
3.6.2.8. Requesting a Virtual Mobile Authenticator OTP: User Perspective
There are three ways a user might request a one-time password to be delivered with either a Primary or Backup Vir-
tual Mobile Authenticator:
2-step Login
Two login prompts are used to provide an easy-to-use login interface for users with Virtual Mobile Authentic-
ator. The first prompt is used to request an OTP, and the second is for entering the received OTP. This can be
used with applications which support 2-step logins eg. Citrix Web Interface, RADIUS with support for Chal-
lenge/Response
Two 1-step Logins
The user must attempt two logins, the first of which will fail but will initiate the sending of an OTP to the user.
This is used when the 2- step login process is not supported - eg. RADIUS without support for Chal-
lenge/Response Web HTTP Basic Authentication.
IDENTIKEY Authentication Server 3.20 – Product Guide 76
3. User Authentication
OTP Request Site
Alternatively, users can go to the OTP Request site when they need an OTP sent, then login normally at the
usual login screen. This method is preferable if a more user-friendly option than the previous is needed.
For more information on the OTP Request Site, refer to the IDENTIKEY Authentication Server Websites Admin-
istrator Guide.
3.6.2.9. Request Method and Keyword
For 2-Step Challenge/Response and Virtual Mobile Authenticator, the method of requesting a challenge or OTP
respectively can be defined in the policy. The methods for Primary and Backup Virtual Mobile Authenticator are
defined separately. The request methods are:
n Password - the static password.
n Keyword - a fixed keyword, which can be blank.
n PasswordKeyword - the static password followed by a fixed keyword, with no whitespace or separating
characters in between.
n KeywordPassword - a fixed keyword followed by the static password, with no whitespace or separating
characters in between.
n KeywordOnly - use the fixed keyword only.
n None - no method, the feature is disabled.
Note
If password is set for the Request Method, and a user's DIGIPASS is still within the grace period, IDENTIKEY
Authentication Server may process the authentication with the password only and not as a 2- Step Chal-
lenge/Response or Virtual Mobile Authenticator login.
The static password in the request method is compared against the DIGIPASS user account's password value.
However, if the DIGIPASS user account does not have a password set, the password has to be verified with back-
end authentication. If there is no back-end authentication and no password in the DIGIPASS user account, the
request methods that use a password will not work.
If the passwords do not match and back-end authentication is enabled, the password will be verified with back-
end authentication.
The methods of requesting these three login processes can be the same. When it recognizes a request, the
IDENTIKEY Authentication Server will verify that there is a DIGIPASS capable of that login process. If there is not, it
will ignore the request.
For example, say that the request methods for Primary and Backup Virtual Mobile Authenticator are both defined
as keyword otp. A user has a Go 3 with Backup Virtual Mobile Authenticator enabled. When they login with the
keyword otp , the IDENTIKEY Authentication Server will produce a Backup Virtual Mobile Authenticator OTP,
because the user does not have a Primary Virtual Mobile Authenticator.
IDENTIKEY Authentication Server 3.20 – Product Guide 77
3. User Authentication
3.6.2.10. Multiple DIGIPASS or DIGIPASS Applications
DIGIPASS users may have multiple DIGIPASS assigned to their user accounts. Those DIGIPASS may have multiple
applications enabled for a DIGIPASS. If so, the IDENTIKEY Authentication Server will need to know:
1. Whether a user is allowed to have multiple DIGIPASS applications assigned.
2. Which DIGIPASS and DIGIPASS Application will be used for a particular login of the user.
The following diagram illustrates an example of how DIGIPASS authenticators and applications can be assigned.
Image 32: Multiple DIGIPASS Assignments
You can configure whether to allow the use of multiple DIGIPASS applications per user. By default, this setting is
enabled.
IDENTIKEY Authentication Server 3.20 – Product Guide 78
3. User Authentication
Note
As of version 3.7, IDENTIKEY Authentication Server also supports the DIGIPASS Multi-Device Licensing and Activ-
ation model.
One DIGIPASS license allows to instantiate several DIGIPASS instances bound to the same DIGIPASS license.
DIGIPASS instances are not different from DIGIPASS activated in the standard process with regard to the rep-
resentation of DIGIPASS applications. IDENTIKEY Authentication Server creates the DIGIPASS instance(s) for a par-
ticular license during the Multi-Device Activation process.
For more information on Multi-Device Licensing and Activation, refer to Section 2.4. DIGIPASS Licensing and Activ-
ation.
Aside from configuring whether multiple DIGIPASS applications per user is allowed, you can also restrict which
DIGIPASS Application is allowed for a specific policy. With this kind of restriction, IDENTIKEY Authentication Server
will only verify OTP against that type of DIGIPASS Application. So if a policy restricts allowed DIGIPASS Applications
to Response-Only, then IDENTIKEY Authentication Server will verify all OTP only against RO applications assigned to
a user.
When considering whether to allow multiple DIGIPASS Applications per user and/or which DIGIPASS Applications to
allow, consider the following table. This table explains how IDENTIKEY Authentication Server authenticates OTP
from each DIGIPASS user account, given the following possible scenarios:
Table 4: OTP Authentication for Scenarios Involving Multiple and Single DIGIPASS Applications
Scenario DIGIPASS user account 1 DIGIPASS user account 2 DIGIPASS user account 3
Multiple DIGIPASS Applic- OTP is authenticated against all OTP is authenticated against all OTP is authenticated against
ations allowed, no policy DIGIPASS Applications from assigned DIGIPASS Applications from assigned the DIGIPASS Application from
restrictions on DIGIPASS DIGIPASS authenticators. DIGIPASS authenticators. assigned DIGIPASS authen-
Applications. ticators.
Multiple DIGIPASS Applic- OTP is authenticated only against OTP is authenticated only against OTP is authenticated against
ations allowed, only RO application1 of both assigned application 1 of assigned application 1 of
applications allowed. DIGIPASS authenticators. DIGIPASS authenticators. assigned DIGIPASS authen-
ticators.
Single DIGIPASS Applic- IDENTIKEY Authentication Server IDENTIKEY Authentication Server OTP is authenticated against
ations allowed, no policy detects multiple DIGIPASS Applications detects multiple DIGIPASS Applications DIGIPASS Application from
restrictions on DIGIPASS assigned and immediately fails the login assigned and immediately fails the assigned DIGIPASS authen-
Applications. attempt. login attempt. ticators.
Single DIGIPASS Applic- IDENTIKEY Authentication Server IDENTIKEY Authentication Server OTP is authenticated against
ations allowed, only RO detects multiple RO DIGIPASS Applic- detects one RO assigned, and authen- DIGIPASS Application from
applications allowed. ations assigned and immediately fails ticates OTP against this application. assigned DIGIPASS authen-
the login attempt. ticators.
Grace periods with multiple DIGIPASS authenticators
For information on grace periods with multiple DIGIPASS authenticators, refer to Section 3.6.2.2. Grace Period.
IDENTIKEY Authentication Server 3.20 – Product Guide 79
3. User Authentication
3.6.2.11. DIGIPASS Start and Expiration Time
The DIGIPASS start time defines a particular date and time when an activated (software) DIGIPASS authenticator
can effectively be used for authentication. The DIGIPASS expiration time defines a particular date and time when a
DIGIPASS authenticator expires and can no longer be used for authentication.
Both, the DIGIPASS start time and the DIGIPASS expiration time can be defined when a DIGIPASS authenticator is
assigned to a user.
If the current date and time is not within the start and expiration time of a DIGIPASS authenticator, that
DIGIPASS authenticator cannot be used for authentication.
3.6.3. Authentication without DIGIPASS
When the DIGIPASS lookup does not return a DIGIPASS record, authentication processing requires a static password
check to succeed. In addition, Self- Assignment is possible when the DIGIPASS lookup does not return any
DIGIPASS.
3.6.3.1. Static Password Verification
With Static Password Verification, the password is compared against the DIGIPASS user account's password value.
If the static password is valid, local authentication succeeds (but note that back-end authentication, if used, can
subsequently still cause the overall login to fail).
Note
In this scenario, back-end authentication (if used) can still subsequently cause the overall login to fail.
However, if the DIGIPASS user account does not have a password set, the password has to be verified with back-
end authentication. If back-end authentication is disabled and there is no password in the DIGIPASS user account,
authentication without DIGIPASS cannot work. Similarly, during Dynamic User Registration (where there is no
DIGIPASS user account yet) the password has to be verified with back-end authentication.
If the passwords do not match and back-end authentication is enabled, the password will be verified with back-
end authentication.
If the Local Authentication setting is Digipass Only, static password verification on its own is not permitted. An OTP
must be used during login. This is possible using Self-Assignment.
3.6.3.2. Self-Assignment
A user can assign a DIGIPASS to their DIGIPASS user account using the Self-Assignment mechanism, when per-
mitted by the policy settings. The Assignment Mode setting must be Self-Assignment.
For Self-Assignment to succeed, the user needs to provide the following:
n A static password, validated by back-end authentication
n The serial number of an available DIGIPASS record
IDENTIKEY Authentication Server 3.20 – Product Guide 80
3. User Authentication
n A valid OTP for the DIGIPASS
n A new Server PIN, if required
The Self-Assignment process is possible during Dynamic User Registration. It is also possible when the Local
Authentication setting is Digipass Only.
When using the DIGIPASS Self-Assignment or Auto-Assignment feature of IDENTIKEY Authentication Server, the
user can reset their Server PIN. When the Assignment Mode is set to Self-Assignment-Pin-Reset or Auto-Assign-
ment-Pin-Reset, the user's Server PIN is automatically reset. This is an optional feature and does not require any
administrator action, once the option has been enabled in the DIGIPASS properties and/or the relevant policy set-
tings have been set accordingly.
Response-Only and Self-Assignment
For a DIGIPASS that supports Response-Only the user needs to enter the following in the password login field,
depending on whether a Server PIN is needed or not:
n SERIALNUMBERpasswordOTP – where a Server PIN is not required.
n SERIALNUMBERpasswordPINOTP – where a Server PIN is required.
n SERIALNUMBERpasswordOTPnewpinnewpin – where a Server PIN is required and no initial PIN was set.
Challenge/Response and Self-Assignment
For a DIGIPASS that supports only Challenge/Response this process requires two steps. In the first step, the static
password and serial number are given. This results in a challenge being returned. If the correct response is given
to the challenge, the self-assignment is successful.
n Step 1: SERIALNUMBERpassword
n Step 2: OTP
Serial Number Format
The SERIALNUMBER may be entered in one of two formats, depending on the Serial No. Separator Policy set-
ting:
n No separator specified – the full 10 digit serial number must be entered, with no dashes (-) or spaces; e.g.
0097123456.
n Separator value specified – the serial number can be entered as written on the back of the DIGIPASS; e.g.
9-712345-6.
3.6.4. User Attributes
User attributes are used by IDENTIKEY Authentication Server to return specific information to a Client Component.
There are two types of user attributes available in IDENTIKEY Authentication Server:
IDENTIKEY Authentication Server 3.20 – Product Guide 81
3. User Authentication
n RADIUS attributes can be returned when handling authentication requests from a RADIUS Client.
n Custom user attributes can be returned to DIGIPASS Authentication Modules, DIGIPASS Plug-Ins and cus-
tom Web applications
User attributes may be set for each DIGIPASS user individually, or to a group of DIGIPASS users. For instructions on
adding user attributes to one or more DIGIPASS user account, refer to the online help in the Administration Web
Interface.
3.6.4.1. RADIUS Attribute Settings
RADIUS reply attributes can be returned with an Access-Accept when handling authentication requests from
a RADIUS Client. The attributes may include authentication parameters or authorization settings.
Image 33: RADIUS Attributes Overview
Acceptable RADIUS attribute names for use with IDENTIKEY Authentication Server are contained in a text file. The
default dictionary file provided with IDENTIKEY Authentication Server is named radius.dct and located in either
<install_dir>\bin (Windows) or /etc/vasco/ias (Linux). It may be edited or replaced, if required, to allow more or
less RADIUS attributes to be used.
Acceptable RADIUS attribute names for use with IDENTIKEY Authentication Server can be uploaded via the Con-
figuration Tool. For more information, refer to the IDENTIKEY Authentication Server Administrator Guide.
Attribute Group
For RADIUS attributes, one or more attribute groups are specified in the policy used for the specific client.
When multiple client components require RADIUS reply attributes, the specified attribute group ensures that
only attributes required by the specific RADIUS client are sent.
IDENTIKEY Authentication Server 3.20 – Product Guide 82
3. User Authentication
Name
The name of the RADIUS attribute. This must conform to a RADIUS attribute name specified in the RADIUS dic-
tionary in use. If an attribute is to be returned multiple times in one transaction with different values, it needs
to be added to the attribute group the required number of times.
Value
The required value of the RADIUS attribute.
3.6.4.2. Custom User Attribute Settings
Custom attributes can be used with OneSpan Plug-Ins and DIGIPASS Authentication Modules.
Image 34: Custom User Attributes Overview
Attribute Group
An attribute group is specified by the client component as a parameter in the authentication request. When
multiple client components are using custom user attributes, the specified attribute group ensures that only
attributes required by the specific client are returned.
Name
A name for the attribute as expected by the client component.
Usage
n Basic indicates that the attribute is for use by DIGIPASS Authentication for IIS Basic for Basic
Authentication.
n Return indicates an SBR return attribute
n Check indicates an SBR check attribute
Value
The required value of the named attribute.
IDENTIKEY Authentication Server 3.20 – Product Guide 83
3. User Authentication
3.7. Back-End Authentication
Back-end authentication describes the process of checking user credentials with another system. It is used primar-
ily for:
n Enabling automatic management features such as Dynamic User Registration and Self-Assignment
n Static password verification for users who do not have a DIGIPASS and for Virtual Mobile Authenticator
n Retrieval of RADIUS attributes from a RADIUS server
n Password replacement to allow the user to log in with just a one-time password, in an environment where
the Windows password is required (e.g. Outlook Web Access)
IDENTIKEY Authentication Server supports back-end authentication with the following systems:
n RADIUS
n Windows back-end authentication
n Microsoft Active Directory (via LDAP)
n NetIQ eDirectory (via LDAP)
n IBM Security Directory Server (via LDAP)
n Custom solution (requires SDK)
The back-end authentication setting indicates whether to perform back-end authentication, and if so, when to do
it. This setting is overridden by the same setting in the DIGIPASS user account, unless that has the value Default.
However, this setting in the DIGIPASS user account would typically be used only for rare special case users.
Using the Windows Group Check in Back-End Mode, this setting can be overridden. If a user is not in the list of
groups, back-end authentication will be performed whether it is enabled or not.
The Back-End Protocol setting indicates which type of back-end authentication should be used. The possible val-
ues for the back-end authentication setting are as follows:
None
The IDENTIKEY Authentication Server will not utilize back-end authentication.
Always
The IDENTIKEY Authentication Server will use back-end authentication for every authentication request.
This setting is required, if you want to use offline authentication for DIGIPASS Authentication for Windows
Logon.
If Needed
back-end authentication will only be used in situations where local authentication is not sufficient and to sup-
port certain features:
n Dynamic User Registration
n Self-Assignment
IDENTIKEY Authentication Server 3.20 – Product Guide 84
3. User Authentication
n Password Autolearn (see below)
n Requesting a challenge or Virtual Mobile Authenticator OTP, when the request method includes a pass-
word
n Static password authentication, when verifying a Virtual Mobile Authenticator password-OTP combination
or during the grace period
Note
When a static password is used it is first verified with the stored static password, if one is used. If the static pass-
word matches the stored static password, no back-end authentication is carried out.
If the static password does not match the stored static password, or the stored static password is not available,
then back-end authentication will be performed.
3.7.1. Stored Static Password
The DIGIPASS user account has a Stored Static Password field. When back-end authentication is used, this field
can be used to:
n Store the static password required for back-end authentication. This means that the user does not need to
type in the static password at each login; they only need enter the OTP. The IDENTIKEY Authentication
Server can retrieve the stored static password from the DIGIPASS user account and use it for back-end
authentication.
n Support password replacement. Back-end authentication is used to learn the static password so that it
can be replayed to the host system (eg. Outlook Web Access) when a successful OTP is given.
3.7.2. Stored Password Proxy
When the Stored Password Proxy setting is enabled in the policy, the IDENTIKEY Authentication Server will retrieve
the stored static password from the DIGIPASS user account. If back-end authentication is required for a login, the
stored static password will be used. If there is a host system (eg. Outlook Web Access), the stored static password
will be returned to it, for it to complete its login process.
However, if the user enters a static password in front of their OTP, the static password they enter will take pre-
cedence over the stored static password. In that case, the stored static password will not be used at all for that
login.
When the Stored Password Proxy setting is not enabled in the policy, the stored static password will not be used
for back-end authentication. If back-end authentication is required for a login, the user will have to enter the static
password. This is done in front of the OTP if an OTP is also used. Similarly, if there is a host system that requires a
static password to be returned, the user will have to enter the static password.
IDENTIKEY Authentication Server 3.20 – Product Guide 85
3. User Authentication
3.7.3. Password Autolearn
When the Password Autolearn setting is enabled in the policy, the IDENTIKEY Authentication Server will auto-
matically store the static password when it is verified by back-end authentication. This can happen at any time
from Dynamic User Registration onwards.
If the user's static password has changed in the back-end authentication system, they will need to provide the
new static password during their next login. This is done in front of the OTP if an OTP is used. When the IDENTIKEY
Authentication Server sees that the user has entered a static password, if it does not match the stored static pass-
word already, back-end authentication will occur to verify the new password. If it is verified, the stored static pass-
word will be updated.
3.7.4. Back-End Server Records
A back-end server record is required when IDENTIKEY Authentication Server uses a RADIUS or LDAP server for
authentication. It is possible to create more than one back-end server record, for fail-over purposes. You can also
allocate different back-end servers for different user domains.
A back-end server record contains connection information for the system to be used. Typically, only one back-end
server record will be required for LDAP back-end authentication, whereas RADIUS back-end authentication will
require a record per RADIUS server to be used.
3.7.4.1. Fail-over Strategy
Each back-end server record is assigned a Priority. This comes into effect when multiple back-end servers are
available, and the IDENTIKEY Authentication Server must decide which to use for a back-end authentication
request. It will attempt to connect to the back-end server with the highest priority rating. If it is not available after
the set number of retries, the IDENTIKEY Authentication Server will attempt to connect to the back-end server with
the next-highest priority rating.
If the IDENTIKEY Authentication Server repeatedly fails to get a response from a back-end server, it will ignore it for
some minutes before trying it again. Therefore, a temporary slow response will not prevent the IDENTIKEY
Authentication Server from using a back-end server. But a consistent availability problem will cause it to stop using
the back-end server for a while, when it has an alternative.
3.7.4.2. Domain-Specific Back-End Servers
Back-end server records may be configured for use with a specific domain. This may be useful when multiple
back-end servers exist with different groups of user records on each.
When the IDENTIKEY Authentication Server has to choose a back-end server, it will search for those records in the
domain identified by the user ID and name resolution process. If any are found, it will only use those back-end serv-
ers for that domain. If none are found, it will use the back-end servers that are not assigned to a domain.
IDENTIKEY Authentication Server 3.20 – Product Guide 86
3. User Authentication
3.7.5. RADIUS back-end authentication
IDENTIKEY Authentication Server can pass RADIUS return attributes from the back-end server to the client. Back-
end authentication is supported with the following protocols:
n PAP
n CHAP
n MSCHAP
n MSCHAP2 with MPPE key generation
3.7.6. Microsoft Active Directory Back-End Authentication Using LDAP Protocol
IDENTIKEY Authentication Server can be configured to query Active Directory via an LDAP connection for back-end
authentication. This is typically used where a supported Windows operating system is not available on the
IDENTIKEY Authentication Server machine.
IDENTIKEY Authentication Server also supports site awareness for Global Catalog-based Active Directory domain
controller lookup. IDENTIKEY Authentication Server queries the Global Catalog for all domain controllers serving the
user currently in process of back-end authentication and contacts the relevant domain controllers according to
their priority in the Global Catalog. In this context, IDENTIKEY Authentication Server identifies the network site to
which the machine that is running IDENTIKEY Authentication Server belongs. Those domain controllers that share
the same site with IDENTIKEY Authentication Server during back-end authentication take precedence over others.
For information on Active Directory User Name Resolution, refer to 3.5.1.2. Active Directory User Name Resolution.
To enable back-end authentication for Active Directory using LDAP:
1. Identify the Active Directory server based on the Active Directory Back-End entries in IDENTIKEY Authentic-
ation Server. If no Active Directory back-end entries have been defined in IDENTIKEY Authentication Server
then an attempt will be made to identify the Active Directory domain controller using the Global Catalog.
2. Bind to Active Directory using the security principal ID and password defined for the Active Directory back-
end if principal details specified. You can use the DN or sAM account name format for the Security Principal
ID.
3. Bind to Active Directory using the security principal ID and password defined for the Active Directory back-
end if principal details specified. The format for the Security Principal ID depends on whether the con-
nection is encrypted or not.
a. If this is an encrypted connection, the format of the security principal ID will be the DN; for
example,
cn=Administrator, cn=User, dc=vasco, dc=com.
b. If this is not an encrypted connection, the format of the security principal ID is either the sAM
account name, for example, administrator, or the DN, as exemplified above.
4. Search Active Directory for the attributes of the user that has to be authenticated. 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.
IDENTIKEY Authentication Server 3.20 – Product Guide 87
3. User Authentication
5. IDENTIKEY Authentication Server will bind to the directory server that handles the authentication request. It
will use the user ID and the password specified in the authentication request received by the IDENTIKEY
Authentication Server. If the bind succeeds, the user authentication is deemed to be successful. If the bind
fails, the authentication is deemed to have failed.
If authentication fails, the attributes retrieved during the search will be used to determine the cause of the failure.
Note
IDENTIKEY Authentication Server only supports SASL.Digest-MD5 binding as the client authentication mechanism
for binding with the supported back-end authentication servers.
Be aware that when using SASL.Digest-MD5 in the following circumstances, the Active Directory password must
be reset:
n when using accounts migrated from a workgroup to a domain for any of the supported Active Directory
versions
n when using accounts migrated from a Windows 2000 Active Directory domain to a domain for any of the
supported Active Directory versions
Note
When upgrading Active Directory domain controllers, the following rule must be followed:
n If a server with Windows group users is promoted to an Active Directory domain controller, you must
reset the Active Directory password for any user that existed on the server before it was promoted.
IDENTIKEY Authentication Server 3.20 – Product Guide 88
3. User Authentication
Image 35: back-end authentication for Active Directory
Note
For instructions on setting up a back-end server record for an Active Directory server, refer to the Administration
IDENTIKEY Authentication Server 3.20 – Product Guide 89
3. User Authentication
Web Interface online help.
3.7.7. NetIQ eDirectory Back-End Authentication Using LDAP Protocol
Procedure 1: Enabling back-end authentication for NetIQ eDirectory
1. Identify the NetIQ eDirectory server based on the NetIQ eDirectory back-end server records in IDENTIKEY
Authentication Server.
2. Bind to NetIQ eDirectory using the security principal DN and password defined for the NetIQ eDirectory
back-end server record, if principal details specified.
3. Search NetIQ eDirectory for the FQDN and attributes of the user that has to be authenticated (starting from
the Base Search DN).
4. Try to authenticate with NetIQ eDirectory using a bind with the FQDN and password of the user to be
authenticated.
If authentication fails, the attributes retrieved during the search will be used to determine the cause of the failure.
After enabling back-end authentication for NetIQ eDirectory, you will need to set up a back-end server record for it
(i.e. register it as a back-end server for IDENTIKEY Authentication Server via the Administration Web Interface). For
more information, refer to the Web Administration Service Help.
Table 5: Supported User Logon Format for NetIQ eDirectory
User ID Format Source of User ID
UserID User ID of the user
MYREALM\userid Fully qualified domain name + user ID of the user
[email protected] User ID attribute of the user + fully qualified domain name
Note
IDENTIKEY Authentication Server only supports SASL Digest-MD5 binding as the client authentication mechanism
for binding with the supported back-end authentication servers.
IDENTIKEY Authentication Server 3.20 – Product Guide 90
3. User Authentication
Image 36: Back-End Authentication for NetIQ eDirectory
Note
For more information about setting up a back-end server record for NetIQ eDirectory, refer to the Administration
IDENTIKEY Authentication Server 3.20 – Product Guide 91
3. User Authentication
Web Interface Help.
3.7.8. IBM Security Directory Server Back-End Authentication Using LDAP Protocol
Procedure 2: Enabling back-end authentication for IBM Security Directory Server
1. Identify the IBM Security Directory Server server based on the IBM Security Directory Server back end
records in IDENTIKEY Authentication Server.
2. Bind to IBM Security Directory Server using the security principal DN and password defined for the IBM
Security Directory Server back end record, if principal details specified.
3. Search the IBM Security Directory Server back-end server for the user to be authenticated based on the
User Object Class Name and the User ID Attribute Name defined on setup.
4. Try to authenticate with IBM Security Directory Server using a bind with the user ID and password of the
user to be authenticated.
If authentication fails, the attributes retrieved during the search will be used to determine the cause of the failure.
In addition, you will also need to:
n Configure IDENTIKEY Authentication Server to authenticate via LDAP SSL.
n After configuring SSL, you will need to set up a back-end server record for IBM Security Directory Server
(i.e. register it as a back-end server for IDENTIKEY Authentication Server via the Administration Web Inter-
face). For more information, refer to the Web Administration Service Help.
Note
When registering a IBM Security Directory Server back end for IDENTIKEY Authentication Server, ensure that the
location entered in the IBM Security Directory Server back end record (in the Administration Web Interface) is the
same as that shown on the Tivoli Web Administration > View Edit > Issued To > cn=<serverid>.
Note
IDENTIKEY Authentication Server only supports Simple binding with SSL as the client authentication mechanism
for binding with the supported instances of IBM Security Directory Server.
3.8. Host Codes
If the Client Component requests a Host Code and the DIGIPASS is capable of generating one, then IDENTIKEY
Authentication Server will generate a Host Code and the application will display it to the user. The user generates a
Host Code on their DIGIPASS and checks that it is the same as the one on the screen.
3.8.1. Host Code Generation and Usage
A DIGIPASS Host Code is computed as follows:
IDENTIKEY Authentication Server 3.20 – Product Guide 92
3. User Authentication
1. The DIGIPASS device generates a one-time password, and splits it into two parts. The first part is used for
end user authentication. The second part is the Host Code and is used for server authentication.
2. The end user sends the first part to the server as proof of identity and keeps the second part secret.
3. The server verifies the one-time password for end user authentication. If valid, the end user is authen-
ticated to the server. The server then computes the second part of the one-time password, i.e. the Host
Code.
4. The server sends the Host Code to the end user, who verifies (visually) whether it matches the Host Code
generated by the DIGIPASS device.
Host Code generation is passed as a parameter in the authentication request. This parameter has two options:
n Optional: only return a Host Code if the DIGIPASS is Host Code-capable.
n Required: DIGIPASS must be Host Code-capable or the request will fail.
3.9. Supported RADIUS Protocols
The following RADIUS protocols are supported by IDENTIKEY Authentication Server:
n PAP
n CHAP
n MSCHAP with MPPE (Microsoft Point-to-Point Encryption)
n MSCHAP2 with MPPE
n EAP-TTLSv0/PAP
n EAP-TTLSv0/CHAP
n EAP-TTLSv0/MSCHAP
n EAP-TTLSv0/MSCHAP2
n EAP-TTLSv0/EAP-MSCHAP2
n EAP-TTLSv0/EAP-GTC
n PEAPv0/EAP-MSCHAP2
n PEAPv0/EAP-GTC
n PEAPv1/EAP-MSCHAP2
n PEAPv1/EAP-GTC
Some protocols do not support all authentication features of IDENTIKEY Authentication Server. Refer to 3.10. Lim-
itations of RADIUS Support in IDENTIKEY Authentication Server and the Login Permutations section of the IDENTIKEY
Authentication Server Administrator Reference for more information.
3.10. Limitations of RADIUS Support in IDENTIKEY Authentication Server
The following sections describe the caveats and limitations of IDENTIKEY Authentication Server in RADIUS support.
IDENTIKEY Authentication Server 3.20 – Product Guide 93
3. User Authentication
3.10.1. Limitations of RADIUS Password Protocols
Some IDENTIKEY Authentication Server features are not supported with CHAP or MSCHAP. These protocols hash
login data together; this prevents separation of various entries.
The unsupported features are outlined below:
n Self-Assignment cannot be performed.
n The Server PIN cannot be changed.
n Challenge/Response is not supported.
n Windows back-end authentication is not supported unless the user ID and Windows password are manu-
ally stored, and Stored Password Proxy is enabled.
n Password Autolearn is not supported, as clear text passwords cannot be identified.
n Virtual Mobile Authenticator OTP request is not supported.
These limitations are also applicable to the following protocols:
n EAP-TTLSv0/CHAP
n EAP-TTLSv0/MSCHAP
n EAP-TTLSv0/MSCHAP2
n EAP-TTLSv0/EAP-MSCHAP2
n PEAPv0/EAP-MSCHAP2
n PEAPv1/EAP-MSCHAP2
The OneSpan User Websites, when utilized, can circumvent many of these problems by allowing users to manage
their account and DIGIPASS authenticators. Users can:
n Perform Self-Assignment
n Change their Server PIN
n Change their own Stored Static Password
3.10.2. Unsupported RADIUS Password Protocols
The following RADIUS password protocols are not supported:
n MSCHAP with LM Hash
n The password change mechanism for MSCHAP and MSCHAP2
3.10.3. Limitations of International Character Support
A number of IDENTIKEY Authentication Server components provide international character support, and some lim-
itations apply:
IDENTIKEY Authentication Server 3.20 – Product Guide 94
3. User Authentication
Database
International character support in the database is dependent on the individual database driver. Refer to the
Encoding and Case Sensitivity topic in the IDENTIKEY Authentication Server Administrator Guide for more
information.
RADIUS
International character support in the IDENTIKEY Authentication Server using the RADIUS protocol is depend-
ent on the RADIUS Client(s) being used. If a RADIUS Client uses UTF-8 encoding, international characters will
be fully supported. If a RADIUS Client uses a localized encoding (eg. ISO-8859-13), the same locale setting
must be configured on each machine.
If IDENTIKEY Authentication Server is used as an intermediary between a RADIUS client and RADIUS server,
check the encoding expected/required by the RADIUS server. If the RADIUS server requires any encoding
format other than UTF-8, you will need to configure IDENTIKEY Authentication Server accordingly.
Web
DIGIPASS Authentication for OWA, both Forms and Basic Authentication options, limit international character
support to a single configured encoding.
DPADMINCMD
DPADMINCMD supports international characters, but your console window must be able to support the char-
acters or they will not display correctly.
3.10.4. Limitations of Web Basic Authentication
In IDENTIKEY Authentication Server, the HTTP Basic Authentication mechanism does not support a 2-step login pro-
cess. In addition, Challenge/Response is also unsupported.
3.10.5. Limitations for Score-Based DIGIPASS Applications
Score-Based DIGIPASS applications do not support CHAP-based RADIUS authentications.
IDENTIKEY Authentication Server 3.20 – Product Guide 95
4. Signature Validation
4. Signature Validation
IDENTIKEY Authentication Server will allow you to sign transaction data using Electronic Signatures generated via
two methods:
n Through a DIGIPASS that is set up to generate Electronic Signatures, or
n IDENTIKEY Authentication Server itself (i.e. virtual signature generation)
An Electronic Signature is based on transaction details entered into the DIGIPASS authenticator. The
DIGIPASS authenticator uses the transaction details and an embedded secret to generate and display an Electronic
Signature. With Virtual Signature Generation , the user supplies the transaction details directly to IDENTIKEY
Authentication Server, which will then generate the Electronic Signature, i.e. the virtual signature. Virtual sig-
natures are delivered to the user via the Message Delivery Component.
Once a user receives the Electronic Signature, they can then use it to sign a transaction, typically through a con-
firmation page (e.g. for finalizing a transaction). This signature will be validated by IDENTIKEY Authentication
Server; if the signature is incorrect or invalid, then the transaction will not be permitted to proceed.
4.1. Signature Validation Process
If a signature is generated with a DIGIPASS authenticator, the signature validation process occurs as follows:
1. The user selects the signature application on their assigned authenticator.
2. The user enters the required transaction details. DIGIPASS can be programmed to accept up to eight trans-
action data fields such as:
n transaction amount
n transaction ID
n destination account number
3. The DIGIPASS authenticator will generate a signature and display it on its screen. The user enters this sig-
nature into the transaction and submits the transaction.
If signature generation is done via IDENTIKEY Authentication Server (i.e. virtual signature generation), the signature
validation process typically occurs as follows:
1. The user initiates the transaction as normal via a client program (e.g. money transfer via online banking
application). The client program then requests an Electronic Signature from the user in order to sign the
transaction.
2. At the same time, the client program submits the required transaction details to IDENTIKEY Authentication
Server, requesting a virtual signature.
3. IDENTIKEY Authentication Server then generates a virtual signature based on the transaction details sup-
plied.
4. IDENTIKEY Authentication Server delivers the virtual signature to the user via e-mail, voice, SMS, or any
supported combination thereof (depending on how Message Delivery Component is configured).
5. The user receives the virtual signature and enters it into the transaction (as requested by the client pro-
gram).
IDENTIKEY Authentication Server 3.20 – Product Guide 96
4. Signature Validation
Once the transaction is signed, it can then be sent to IDENTIKEY Authentication Server for validation. The signature
validation process from this point onwards is identical for transactions signed by either normal Electronic Sig-
natures (generated via DIGIPASS) or virtual signatures (generated via IDENTIKEY Authentication Server).
4.1.1. Signature Validation with Secure Channel and DIGIPASS
As of IDENTIKEY Authentication Server 3.7, signatures can also be validated using the Secure Channel feature with
DIGIPASS authenticator compliant with this feature. Signature validation with the Secure Channel feature is used
for validating transactions such as e.g. online banking but is also used to add devices, activate DIGIPASS licenses
and instances in a Multi-Device Licensing and Activation Scenario. For more information on this, refer to Section
2.4. DIGIPASS Licensing and Activation.
1. The user logs in to the client application and enters the required transaction details.
2. After entering the transaction details, the user scans either a QR code or a color QR code, which are
provided by the client application.
3. The DIGIPASS authenticator displays the transaction signature and the user enters this in the client applic-
ation to complete the transaction.
4.1.2. Real-Time Signature Validation
Real-Time Signature Validation is generally used to provide security for transactions that require quick responses.
It is typically used by online banking applications.
With Real-Time Signature Validation, a user creates a transaction. The transaction normally requires a signature,
so the user enters the relevant details into their DIGIPASS. The DIGIPASS produces a signature and the user enters
this into the website, which then submits the transaction.
The transaction details and signature are verified by IDENTIKEY Authentication Server, and a status message is
returned straight to the web page the user is on. The user knows within the time it takes to process a normal trans-
action whether or not the submitted transaction has been verified.
4.1.3. Deferred Signature Validation
Deferred Signature Validation is signature validation that is not performed in real-time. In typical cases that use
this validation, a user submits a transaction online with the signature generated by the DIGIPASS. The transaction
will then enter a queue to be verified. The user receives a message that the transaction has gone into a queue. A
batch job picks up the transaction and verifies it against the policies and details of the DIGIPASS. The user may not
know until minutes or hours later that the transaction has been signed and verified.
It is important in this case for the user to keep a record of the time the transaction was submitted, as this may be
important if the transaction is challenged.
IDENTIKEY Authentication Server 3.20 – Product Guide 97
4. Signature Validation
4.2. Electronic Signature Application Types
IDENTIKEY Authentication Server supports the following types of signature applications.
4.2.1. Time-Based Signature
A signature application may be time-based. This means that the DIGIPASS will generate a different signature for
the same input data at different times.
The signature validation procedure relies on the time on the DIGIPASS and the time on IDENTIKEY Authentication
Server being synchronized to within an acceptable tolerance. Each time a one-time password or a signature is gen-
erated, the IDENTIKEY Authentication Server records the time difference between the DIGIPASS and itself.
The time-based signature validation procedure also uses Time Steps to verify signatures. A Time Step is a setting
which specifies the number of seconds between generations of a one- time password on a DIGIPASS. The
IDENTIKEY Authentication Server will use the time step and the known difference in time between itself and the
DIGIPASS to verify signatures.
Use the Signature Time Window policy setting to set the tolerance allowable for signature verification.
Time based signatures can be real-time or deferred. If deferred time-based signatures are used, they may be re-
verified at a later date by comparing the input details against the signature produced by the DIGIPASS, as long as
the time the transaction was performed is known.
4.2.2. Event-Based Signature
A signature application may also be event-based. This means that it contains a numeric counter that increases
every time a signature is generated.
The signature process relies on an event counter to enable each signature to be unique. The DIGIPASS and
IDENTIKEY Authentication Server need to have synchronized event counters. The tolerance for the difference
between the event counters can be set by using the Event Window policy setting.
During Real-Time Signature Validation the event counter on IDENTIKEY Authentication Server is updated with the
value used by the DIGIPASS, to keep the two event counter values synchronized.
During Deferred Time Signature Validation the event counters for transactions generated on the DIGIPASS may get
out of step with the event counter held on IDENTIKEY Authentication Server. The Event Window policy setting can
enable signed transactions to be processed in any order without causing a verification error.
IDENTIKEY Authentication Server 3.20 – Product Guide 98
4. Signature Validation
4.2.3. Static Signature
These signatures are generated using neither time or event counter. They will always produce the same signature
for the same input. There is no difference between real-time and deferred time with these signatures.
4.3. Signature Verification Process
Electronic Signatures are verified by IDENTIKEY Authentication Server using a number of specific checks, in the fol-
lowing sequence:
1. Component checks
2. Policy checks
3. User account lookup and checks
4. Signature validation
5. Finalization
The following sections describe each step in detail.
4.3.1. Component Checks
IDENTIKEY Authentication Server will try to identify the application from which the request for registration came.
There must be a component record on the data store for that application. A client component record must exist for
the Signature Verification application and location from which it connects to the server. The component type is set
as a parameter by the application; the location is the source IP address of the SOAP address.
Note
A client component with an IP address range (IPv4 CIDR notation) as component location will be used to handle
requests from any client within that IP address range. If two (or more) matching client components with over-
lapping IP address ranges are found, the client component with the smaller IP address range (more specific)
takes precedence and will be used to serve the request.
4.3.2. Policy Checks
IDENTIKEY Authentication Server identifies the policy to use in the signature authentication from the Client Com-
ponent record and checks the validity of the policy.
4.3.3. User Account Lookup and Checks
IDENTIKEY Authentication Server checks the user account to :
IDENTIKEY Authentication Server 3.20 – Product Guide 99
4. Signature Validation
n Ensure that the user ID and domain have been defined
n Perform the Windows Group Check if necessary
n Check whether a user account exists
n Check whether the user account is disabled or locked if it already exists.
If the DIGIPASS user account is locked, IDENTIKEY Authentication Server verifies whether a user auto-
unlock attempt is possible (see 10.5. DIGIPASS User Account Auto-Unlock).
Dynamic User Registration is NOT possible. If the user account does not exist, then the check will fail.
4.3.4. Signature Validation
A search is performed for a DIGIPASS that is assigned to the user that fulfils the signature policy limits. If more than
one DIGIPASS is found, the list is filtered using the serial number for the DIGIPASS. This serial number will be
passed to the signature process as a parameter.
Note
When designing a web page that will allow transactions to be signed, ensure that users with multiple DIGIPASS
can enter a serial number to identify which DIGIPASS is being used.
When the correct DIGIPASS is identified, the DIGIPASS type is checked. The DIGIPASS type must be either SG (Sig-
nature) or MM (Multi Mode) to allow signatures. The signature is then verified and a response is produced.
4.3.5. Finalization
The relevant parts of the Data Store are updated after the signature validation has been carried out successfully. A
response is produced. The audit data is updated with the transactions that took place and the result of those trans-
actions.
If the Web Application requests a confirmation code and the DIGIPASS is capable of generating one, then
IDENTIKEY Authentication Server will generate a confirmation code and the application will display it to the user.
The user generates a Confirmation Code on their DIGIPASS and checks that it is the same as the one on the screen.
Confirmation code generation is passed as a parameter in the authentication request. There are two options:
n Optional: only return a confirmation code if the DIGIPASS is confirmation code-capable
n Required: DIGIPASS must be confirmation code-capable or the request will fail.
4.4. Policy Settings Relevant to Signature Validation
The following policy settings affect signature verification:
IDENTIKEY Authentication Server 3.20 – Product Guide 100
4. Signature Validation
n Event Window: the allowable difference between the DIGIPASS event counter and IDENTIKEY Authentic-
ation Server event counter.
n Online Signature Level: specifies how signatures will be verified.
n Signature Time Window: Shows the acceptable difference in time between the time set on the DIGIPASS
and the time set on IDENTIKEY Authentication Server for signatures. The lowest value is 2, the highest is
500.
For more information on these settings, refer to the Policy Properties section in the Field Listings section of the
IDENTIKEY Authentication Server Administrator Reference.
Note
For signature validation processes with the Secure Channel feature, IDENTIKEY Authentication Server provides
the default policy IDENTIKEY Signature Validation with Secure Channel.
IDENTIKEY Authentication Server 3.20 – Product Guide 101
5. Software DIGIPASS Provisioning
5. Software DIGIPASS Provisioning
This chapter provides an overview of the different components involved in the provisioning of software DIGIPASS
authenticators, and a high-level description of the provisioning process. For more detailed information on software
DIGIPASS, refer to Section 2.3.2. Software DIGIPASS authenticator.
5.1. Provisioning Overview
In IDENTIKEY Authentication Server, the term Provisioning refers to delivery, registration, and activation of the soft-
ware. The following sections describe each of these steps in detail.
5.1.1. Software Delivery
You are free to deliver the software to your customers in any way you choose. You can either deliver software to
users, or allow them to download the software from a secure site. An Activation Code is required to activate the
software DIGIPASS authenticator or authenticators such as DP110. This code may be delivered via two methods:
Online Delivery
With this method, the activation code is delivered directly to the application that is going to use it. If the activation
code is delivered in this way, the user will never see it. This option is available for DIGIPASS for Web, DP110, Mobile
Authenticator Studio, and the Mobile Authenticator.
Offline Delivery
With offline delivery, available for DIGIPASS for Web and Mobile Authenticator Studio , the activation code is
delivered via a mechanism such as email, text message, or fax.
In DIGIPASS for Web the activation code will typically be delivered in an email containing a link. The applet reads
the activation code from the link.
5.1.2. User/DIGIPASS Registration
The DIGIPASS records must be imported from a *.dpx file before registration can occur.
Each software DIGIPASS user requires a DIGIPASS user account on IDENTIKEY Authentication Server. The user
accounts can either be imported into IDENTIKEY Authentication Server, created individually, or created dynamically
during registration if Dynamic User Registration is available.
For software DIGIPASS to work, a DIGIPASS record needs to be allocated to the user account. This can be done in
two ways:
IDENTIKEY Authentication Server 3.20 – Product Guide 102
5. Software DIGIPASS Provisioning
n Manually by an administrator using, for example, the Administration Web Interface.
n Automatically, where IDENTIKEY Authentication Server will select a random DIGIPASS authenticator and
assign it to the new DIGIPASS user account as it is created . In IDENTIKEY Authentication Server this func-
tionality is known as Auto-Assignment.
Afterward, an activation code is generated and sent to the user.
5.1.3. Activate Software
Each software DIGIPASS needs to be activated before it can be used. This means that IDENTIKEY Authentication
Server is informed that all the components are in place for the software DIGIPASS and you are ready to use it.
There are two stages to activation:
n Delivering the activation code to the software
n Sending the first one-time password to the server.
Image 37: Steps of Provisioning
5.1.4. Delayed Activation
The DIGIPASS start time defines a particular date and time when an activated (software) DIGIPASS authenticator
can effectively be used for authentication. If defined in the effective policy, the start time can be automatically cal-
culated based on a delayed activation period when assigning/registering the DIGIPASS authenticator to a user.
Although the software DIGIPASS authenticator has already been activated, IDENTIKEY Authentication Server will not
allow it to be used for authentication, until the start time has been reached. This is called delayed activation.
IDENTIKEY Authentication Server 3.20 – Product Guide 103
5. Software DIGIPASS Provisioning
If defined in the effective policy, two separate notification messages are sent to the respective user to indicate
delayed activation:
a. The activation delayed notification is sent when the DIGIPASS authenticator is assigned/registered to the
user.
b. The activation completed notification is sent when the start time has been reached, i.e. when the
DIGIPASS authenticator can effectively be used.
The notification messages are sent using Message Delivery Component (MDC) and handled independently of each
other: if defined, either both, none, or either one is sent.
5.1.5. Provisioning Components
There are two required components and one optional component required to implement provisioning:
Web Application (customized)
The Web Application controls the user interaction during provisioning. The Web Application uses the SOAP SDK to
communicate with IDENTIKEY Authentication Server. Refer to the SOAP SDK documentation for more information.
The Web Application should be able to:
n Make the software DIGIPASS available for download
n Facilitate delivery of the activation code to the user
n Send the first one-time password to IDENTIKEY Authentication Server
IDENTIKEY Authentication Server
IDENTIKEY Authentication Server handles DIGIPASS user account and DIGIPASS records. It generates activation
codes, verifies one-time password, and stores static passwords.
Back-End System
The back-end system can be used by IDENTIKEY Authentication Server for Dynamic User Registration and/or static
password verification. For more information, refer to 3.7. Back-End Authentication.
5.1.6. User Authentication during Provisioning
The user authentication method during a software DIGIPASS provisioning process depends on two factors: the local
authentication method set in the relevant policy, as well as on whether the user already has an activated DIGIPASS
authenticator.
The possible local authentication settings and their implications on the provisioning process are:
n If Local Authentication is set to DIGIPASS/ Password during Grace Period, the user must use their static
password when activating their first DIGIPASS authenticator. Upon successful completion of the DIGIPASS
IDENTIKEY Authentication Server 3.20 – Product Guide 104
5. Software DIGIPASS Provisioning
activation the grace period ends, and any future provisioning operations will require the user to authen-
ticate with a one-time password.
n If Local Authentication is set to DIGIPASS or Password, the user must use their static password when activ-
ating their first DIGIPASS authenticator. After this, the user can authenticate with their static password or
their DIGIPASS authenticator during any future provisioning operations.
Warning
If the local authentication method is DIGIPASS Only, a user who is activating their first DIGIPASS authenticator will
be unable to complete the activation because they are not allowed to authenticate with their static password.
For more information about local authentication methods, see 3.6. Local Authentication.
5.2. Provisioning Scenarios
The following scenarios show how provisioning will work for different DIGIPASS authenticators in different situ-
ations.
The user authentication method during the provisioning process may vary depending on the local authentication
policy setting, and on whether the user already has an activated DIGIPASS authenticator. For more information,
see 5.1.6. User Authentication during Provisioning.
Table 6: Provisioning Scenarios
Scenarios User User knows Static Provisioning Policy
Account? Password?
Local Authentication Back- DIGIPASS Back-End Pro- Dynamic
End Type tocol User Regis-
Auth tration
Mobile Authenticator Y Yes, at least for a DIGIPASS/Password None MOB40 - -
Studio Online Activation user's first pro- during Grace
visioning operation. Period or DIGIPASS
See 5.1.6. User or Password
Authentication during
Provisioning
Multi-Device Activation N Yes, at least for a DIGIPASS/Password Always DAL10 Windows, Enabled
of compliant authen- user's first pro- during Grace or If RADIUS, LDAP,
ticators (e.g. Mobile visioning operation. Period or DIGIPASS Needed custom
Authenticator Studio, See 5.1.6. User or Password
DIGIPASS 760) Authentication during
Provisioning.
DIGIPASS for Web 1 Y Y None None WEB10 - -
DIGIPASS for Web 2 Y Y Digipass Only or None WEB10 - -
DIGIPASS/Password
during Grace
Period
IDENTIKEY Authentication Server 3.20 – Product Guide 105
5. Software DIGIPASS Provisioning
Table 6: Provisioning Scenarios (continued)
Scenarios User User knows Static Provisioning Policy
Account? Password?
Local Authentication Back- DIGIPASS Back-End Pro- Dynamic
End Type tocol User Regis-
Auth tration
DIGIPASS for Web 3 N Y Digipass Only or Always WEB10 Windows, Enabled
DIGIPASS/Password or If RADIUS, LDAP,
during Grace Needed custom
Period
DP110 1 Y Y None DP110 - -
DP110 2 N Y None Always DP110 Windows, -
RADIUS, LDAP,
custom
5.2.1. Mobile Authenticator Studio
In a scenario involving Mobile Authenticator Studio, activation codes are encrypted with pre-loaded static pass-
words.
Pre-Conditions
n The user account has been created on IDENTIKEY Authentication Server
n The user knows their static password (in case of first-time software DIGIPASS provisioning)
n The static password has been imported into IDENTIKEY Authentication Server
n The provisioning policy has been defined with the following settings
n Local authentication (DIGIPASS/Password during Grace Period or DIGIPASS or Password)
n No back-end authentication (None)
n DIGIPASS type is the appropriate type for the version of Mobile Authenticator Studio being used.
Note
User authentication during software DIGIPASS provisioning may vary depending on the local authentication policy
settings, and on whether the user already has an activated DIGIPASS authenticator. For more information, see
5.1.6. User Authentication during Provisioning.
IDENTIKEY Authentication Server 3.20 – Product Guide 106
5. Software DIGIPASS Provisioning
Image 38: Mobile Authenticator Studio Offline Activation Process
There is a choice of activation options for Mobile Authenticator Studio 4.x DIGIPASS provisioning, and the choice of
activation option affects how the Mobile Authenticator Studio authenticator is provisioned:
n Offline activation - manual or via QR code
n Standard online activation
n Advanced online activation
n Multi-Device Activation
IDENTIKEY Authentication Server 3.20 – Product Guide 107
5. Software DIGIPASS Provisioning
5.2.1.1. Offline Activation - manual or via QR code
Offline activation is performed by the administrator who assigns the Mobile Authenticator Studio 4.x authenticator
to a user, and then uses the Administration Web Interface or the Active Directory Users and Computers Extension to
generate the activation data. When the activation data has been generated, it has to be entered in to the activ-
ation screen in the Mobile Authenticator Studio application on the mobile phone. The activation data can be sent
via SMS or email, or it can be scanned using a QR code or a color QR code. The activation code is entered and the
transaction is committed on the phone.
If a bind is required, the administrator has to manually bind the device using the Administration Web Interface or
the Active Directory Users and Computers Extension.
The entire mobile phone, with activated Mobile Authenticator Studio application is then distributed to the user.
IDENTIKEY Authentication Server 3.20 – Product Guide 108
5. Software DIGIPASS Provisioning
Image 39: Mobile Authenticator Studio Online Activation Process
5.2.1.2. Standard Online Activation
The user enters their user ID, password, domain and mobile phone number into the provisioning Web site standard
registration page. The provisioning Web site then verifies with IDENTIKEY Authentication Server that the user is
valid and then assigns a Mobile Authenticator Studio DIGIPASS and sends an SMS with the URL to be used to
IDENTIKEY Authentication Server 3.20 – Product Guide 109
5. Software DIGIPASS Provisioning
download the Mobile Authenticator Studio package. The registration identifier and activation password are then
displayed on the provisioning Web site. The user must then download the Mobile Authenticator Studio package,
and enter the registration identifier and activation password into the Mobile Authenticator Studio application on the
phone.
When the user has entered the registration identifier and activation password, the mobile phone sends a request
to the provisioning Web site for the activation data. The provisioning Web site sends the activation data back to the
mobile phone, which will then automatically activate the Mobile Authenticator Studio application. After this, if a
bind is required, the Mobile Authenticator Studio application will request the bind data and will bind DIGIPASS.
The user then receives a response on the mobile device indicating whether the activation has been successful.
5.2.1.3. Advanced Online Activation
Advanced Online activation is performed by the user and uses the DIGIPASS Software Advanced Provisioning Pro-
tocol (DSAPP) protocol. The difference between advanced online activation and standard online activation is the
way that the one-time password is generated when DIGIPASS is used. If you intend to use the DSAPP protocol, you
must perform advanced online activation. If you do not intend to use the DSAPP protocol when generating OTPs,
you must use standard online activation.
The DSAPP protocol can be used for activation, providing it has been enabled on IDENTIKEY Authentication Server.
If the DSAPP protocol is to be used, the user has to enter a user ID, domain and password into the
DSAPP registration page of the provisioning Web site. The provisioning Web site verifies with IDENTIKEY Authentic-
ation Server that the user is valid and then assigns a Mobile Authenticator Studio DIGIPASS and sends an SMS with
the URL to be used to download the Mobile Authenticator Studio package. The registration identifier and activation
password are then displayed on the provisioning Web site. The user must then download the Mobile Authenticator
Studio package, and enter the registration identifier and activation password into the Mobile Authenticator Studio
application on the phone.
When the user has entered the registration identifier and activation password, the mobile phone sends a request
to the provisioning Web site for the activation data. The provisioning Web site sends the activation data back to the
mobile phone, which will then automatically activate the Mobile Authenticator Studio application. After this, if a
bind is required, the Mobile Authenticator Studio application will request the bind data and will bind DIGIPASS.
The user then receives a response on the mobile device indicating whether the activation has been successful.
5.2.2. Multi-Device Activation
This section describes the post-deployment DIGIPASS provisioning using the Multi-Device Licensing and Activation
feature of IDENTIKEY Authentication Server. For more information on Multi-Device Licensing and Activation, refer to
Section 2.4. DIGIPASS Licensing and Activation.
Note
A DIGIPASS authenticator compliant with Multi-Device Licensing is required to perform Multi-Device Activation, for
IDENTIKEY Authentication Server 3.20 – Product Guide 110
5. Software DIGIPASS Provisioning
instance Mobile Authenticator Studio and DP760.
During the provisioning procedures as described below a DIGIPASS instance is loaded into a DIGIPASS device.
These procedures are executed each time a new DIGIPASS instance needs to be loaded into a DIGIPASS device.
The following preconditions apply for the provisioning procedure to succeed:
n The user account has not been created on IDENTIKEY Authentication Server
n The user knows their static password (in case of first-time software DIGIPASS provisioning)
n The provisioning policy has been defined with the following settings:
n Local Authentication (DIGIPASS/Password during Grace Period or DIGIPASS or Password)
n Back-end Authentication (Always or If Needed)
n Back-end Protocol (Windows, RADIUS, LDAP Back-End Authentication, or custom name)
n Dynamic User Registration is enabled
Note
User authentication during software DIGIPASS provisioning may vary depending on the local authentication policy
settings, and on whether the user already has an activated DIGIPASS authenticator. For more information, see
5.1.6. User Authentication during Provisioning.
The first step in the provisioning procedure is to register with the system to start the post-deployment provisioning
of a new DIGIPASS device.
Procedure 3: Register a DIGIPASS license
1. Start a provisioning registration operation to provide the user credentials to IDENTIKEY Authentication
Server.
2. IDENTIKEY Authentication Server checks that a user account is available, validates the user credentials,
and queries for DIGIPASS licenses assigned to your user. The system then generates Activation Message 1
and includes it in the response envelope.
3. The client application provides Activation Message 1 in form of an image - scan this image with the
DIGIPASS authenticator that supports the Multi-Device Licensing model.
4. The DIGIPASS device generates and displays a device code.
Note
If no DIGIPASS license is assigned to the user, IDENTIKEY Authentication Server checks if Auto-Assignment has
been set in the policy used, and will search a random available DIGIPASS license which it assigns to the end user.
When Auto-Assignment has not been enabled in the policy, the provisioning operation fails.
When IDENTIKEY Authentication Server queries for DIGIPASS licenses assigned to the user but there are no activ-
ations left for this particular DIGIPASS license, the system will return an error message explaining that the activ-
ation threshold for this license has been reached.
After you have registered a DIGIPASS license, the second step in the Multi-Device Activation process is to register a
device.
IDENTIKEY Authentication Server 3.20 – Product Guide 111
5. Software DIGIPASS Provisioning
Procedure 4: Register a DIGIPASS device
1. The client application starts a provisioning DIGIPASS authenticator registration operation and provides the
end user's registration identifier and the device code to IDENTIKEY Authentication Server.
2. The server retrieves the registration context (e.g. the DIGIPASS serial number used in the previous step),
validates the device code, and generates a new DIGIPASS instance using the DIGIPASS license.
3. The server then generates Activation Message 2 for the DIGIPASS license and includes it in the response
envelope.
4. The client application provides Activation Message 2 in form of an image - scan this image with the
DIGIPASS authenticator that supports the Multi-Device Licensing model.
5. The DIGIPASS authenticator generates and displays a signature.
After registering the device, the end user activates a new DIGIPASS instance. Based on Activation Message 2, a sig-
nature generated with the DIGIPASS instance is validated. With this, the new DIGIPASS instance is activated.
5.2.2.1. Banking Scenario: Self-Provisioning and Administrating of DIGIPASS Authenticators in Multi-Device Activ-
ation
This section describes DIGIPASS self-provisioning and administrating in a banking context using the Multi-Device
Licensing and Activation feature of IDENTIKEY Authentication Server, with compliant DIGIPASS authenticators. This
includes generation and administration of an activation letter for the end user who then activates a new DIGIPASS.
Generating and sending an activation letter
The end user requests the bank to send them an activation letter for activating DIGIPASS authenticators. Once the
end user has entered the banking credentials to the client application, the system validates these credentials, cre-
ates a user account in the IDENTIKEY Authentication Server database, and assigns a DIGIPASS license to the newly
created user account. On the basis of Activation Message 1 which the system generates, the client application gen-
erates a color QR code and prints an end user-specific activation letter that includes the serial number of the
DIGIPASS license and the color QR code.
Note
If no DIGIPASS license is available for assignment, the provisioning operation fails, and the client application noti-
fies the end user to contact their bank.
Also, for this operation to succeed, the policy specified in the client record in IDENTIKEY Authentication Server for
the client application must allow Auto-Assignment.
Alternatively, the user administrator can also initiate sending activation letter to end users by connecting to the cli-
ent application, entering the IDENTIKEY Authentication Server credentials, and uploading a .dpx file to the client
application. The system creates a DIGIPASS record to process all .dpx files. The user administrator also uploads a
user .csv file that aligns the DIGIPASS licenses with the user IDs for assignment. The system then generates Activ-
ation Message 1 and returns it to the client application which generates a color QR code on the basis of this mes-
sage, and prints an end user-specific activation letter which includes the serial number of the DIGIPASS license and
the color QR code. The activation letters are sent to the end users by post.
IDENTIKEY Authentication Server 3.20 – Product Guide 112
5. Software DIGIPASS Provisioning
Activating a new DIGIPASS instance in the DIGIPASS device
Once the end user has received the activation letter, they scan the color QR code contained in the letter with a
DIGIPASS device that is compliant with the Multi-Device Licensing and Activation feature. For more information on
compliant DIGIPASS authenticator, refer to Section 2.4. DIGIPASS Licensing and Activation . The end user also
enters the banking credentials, the serial number contained in the activation letter, and the device code the
DIGIPASS authenticator has generated upon scanning the color QR code. The system validates the end user's cre-
dentials in a back-end directory and verifies the DIGIPASS license with the provided serial number assigned to the
local user ID of the end user. The system adds the new device, creates a new DIGIPASS instance, and generates
Activation Message 2. This message is returned together with a request key and the serial number of the new
DIGIPASS instance to the client application.
The client application generates a color QR code that represents Activation Message 2 - the end user scans this
image with the same DIGIPASS device that was used to scan the color QR code from the activation letter. With this,
the DIGIPASS device creates a new DIGIPASS instance based on Activation Message 2, and displays an activation
signature to be entered into the client application by the end user. The system validates the activation signature,
returns the result to the client application which displays this result to the end user who then disconnects from the
client application.
5.2.3. DIGIPASS for Web
There are three scenarios that can be employed when activating DIGIPASS for Web, and each one has different
pre-conditions. Which scenario is employed will depend on how IDENTIKEY Authentication Server is implemented.
5.2.3.1. Scenario 1: Activation Codes are Encrypted with Pre-Loaded Static Passwords
Pre-Conditions
n The user account has been created on IDENTIKEY Authentication Server
n The user knows their static password
n The static password has been imported into IDENTIKEY Authentication Server
n The provisioning policy has been defined with the following settings:
n No local authentication (None)
n No back-end authentication (None)
Process
IDENTIKEY Authentication Server 3.20 – Product Guide 113
5. Software DIGIPASS Provisioning
Image 40: DIGIPASS for Web Scenario 1 Process
The user enters their user ID, email address and PIN on the website. If registration is successful, the DIGIPASS for
Web is provided with the serial number of the DIGIPASS that is to be activated and an encrypted activation code.
IDENTIKEY Authentication Server 3.20 – Product Guide 114
5. Software DIGIPASS Provisioning
Note
In this case, the PIN is not sent to the server; rather, it is used locally by the DIGIPASS for Web applet.
The user will have to re-enter their user ID, PIN and password to decrypt the activation code and complete activ-
ation. The applet decrypts the activation code, activates itself and sends a one-time password to the server.
The user then receives a response indicating whether the activation has been successful.
Options
To make sure that the user changes their static password, extra fields can be added to the second page in this
scenario. Fields can be added to the input page so that the user can enter a new static password, and then enter it
again for confirmation. The user needs to do this so that the original password can only be used once, for activ-
ation. The new password can be used for re-activation.
For more information, refer to 5.4.1. Software DIGIPASS Reactivation.
5.2.3.2. Scenario 2: Pre-Loaded User Accounts and Static Passwords
Pre-Conditions
n The user account has been created on IDENTIKEY Authentication Server
n The user knows their static password
n The static password has been imported into IDENTIKEY Authentication Server
n The provisioning policy has been defined with the following settings:
n Local authentication (Digipass Only or DIGIPASS/Password during Grace Period)
n No authentication (None)
IDENTIKEY Authentication Server 3.20 – Product Guide 115
5. Software DIGIPASS Provisioning
Process
Image 41: DIGIPASS for Web Scenario 2 Process
The user enters their user ID, email address, static password and PIN on the registration website. If registration is
successful, the serial number of the DIGIPASS that is to be activated and an activation code are delivered to the
DIGIPASS for Web applet.
IDENTIKEY Authentication Server 3.20 – Product Guide 116
5. Software DIGIPASS Provisioning
The user re-enters the user ID and PIN. DIGIPASS for Web generates a one-time password and then submits this
with the serial number to the server. Activation then takes place.
The user will then receive a response indicating whether the activation has been successful.
Options
To make sure that the user changes their static password, extra fields can be added to the second page in this
scenario. Fields can be added to the input page so that the user can enter a new static password, and then enter it
again for confirmation. The user needs to do this so that the original password can only be used once, for activ-
ation. The new password can be used for re-activation.
For more information, refer to 5.4.1. Software DIGIPASS Reactivation.
5.2.3.3. Scenario 3: Dynamic Registration Using Back-End System
Pre-Conditions
n The user account has not been created on IDENTIKEY Authentication Server
n The user knows their static password for their account in the back-end system
n The provisioning policy has been defined with the following settings:
n Local authentication ( Digipass Only or DIGIPASS/Password during Grace Period)
n Back-end authentication (Always or If Needed)
n Back-end protocol (Windows, RADIUS, LDAP Back-End authentication, or custom name)
n Dynamic User Registration enabled
IDENTIKEY Authentication Server 3.20 – Product Guide 117
5. Software DIGIPASS Provisioning
Process
Image 42: DIGIPASS for Web Scenario 3 Process
IDENTIKEY Authentication Server 3.20 – Product Guide 118
5. Software DIGIPASS Provisioning
The procedure for this scenario is very similar to that of 5.2.3.2. Scenario 2: Pre-Loaded User Accounts and Static
Passwords; the difference for the IDENTIKEY Authentication Server is that the back-end system is used to verify the
user ID and password. If both are OK, the account is created automatically in IDENTIKEY Authentication Server.
Both scenario 2 and 3 are identical from the user's perspective.
Options
To make sure that the user changes their static password, extra fields can be added to the second page in this
scenario. Fields can be added to the input page so that the user can enter a new static password, and then enter it
again for confirmation. The user needs to do this so that the original password can only be used once, for activ-
ation. The new password can be used for re-activation.
For more information, refer to 5.4.1. Software DIGIPASS Reactivation.
5.2.4. DIGIPASS 110 Provisioning
The DIGIPASS 110 is a hardware/software combination DIGIPASS. It does not require any software to be installed
on the client-side to enable it to run, but it does require the correct policy settings to be provided, followed by activ-
ation.
There are two scenarios that can be employed when activating a DIGIPASS 110. They both have different pre-con-
ditions. Which scenario is used will depend on how IDENTIKEY Authentication Server is implemented.
5.2.4.1. Scenario 1: No back-end authentication
Pre-Conditions
n The user account has been created
n The user knows their historical secret
n Historical Secret imported in IDENTIKEY Authentication Server (as static password)
n The provisioning policy has been defined with the following settings:
n Local authentication
n No back-end authentication
n DIGIPASS type is DIGIPASS 110
IDENTIKEY Authentication Server 3.20 – Product Guide 119
5. Software DIGIPASS Provisioning
Process
Image 43: DIGIPASS 110 Scenario 1
IDENTIKEY Authentication Server 3.20 – Product Guide 120
5. Software DIGIPASS Provisioning
The user opens the browser on their computer, and goes to the registration page of the DIGIPASS 110 provisioning
website. The DIGIPASS 110 provisioning website generates a challenge which will be used to encrypt the new
Server PIN. The user enters their user ID, static password, new Server PIN, confirmation of new Server PIN, and
DIGIPASS 110 serial number on the registration website. The DIGIPASS 110 Applet generates a Challenge Encrypted
Static Password (CESPR) using the generated challenge and the new Server PIN.
On the server-side, the CESPR is verified. If verification is successful the DIGIPASS 110 is assigned to the user, and
the initial PIN is set. The DIGIPASS grace period is set according to pre-defined parameters. The activation page is
returned if the provisioning is successful, or an error message will be returned if the provisioning is not successful.
5.2.4.2. Scenario 2: Back-end authentication always enabled
Pre-Conditions
n The user account has NOT been created
n The user knows historical secret to allow authentication by a legacy back-end system
n The provisioning policy has been defined with the following settings:
n NO local authentication (None)
n Back-end authentication (Always)
n DIGIPASS type is DIGIPASS 110
IDENTIKEY Authentication Server 3.20 – Product Guide 121
5. Software DIGIPASS Provisioning
Process
Image 44: DIGIPASS 110 Scenario 2
The user enters their user ID, static password, challenge, CESPR, and DIGIPASS 110 serial number on the regis-
tration website. On the server-side, the user is authenticated on the back end. If the back-end authentication is
successful the user is then registered to using Dynamic User Registration. The DIGIPASS 110 is then assigned to
the user, and the initial PIN is set. The DIGIPASS grace period is set according to pre-defined parameters.
A response will be received indicating whether the activation has been successful.
IDENTIKEY Authentication Server 3.20 – Product Guide 122
5. Software DIGIPASS Provisioning
5.3. Registration Process for Software DIGIPASS
The following diagram summarizes how software DIGIPASS is registered:
Image 45: Software DIGIPASS Registration Process
The following sections detail each step in the registration process.
Identify Component
IDENTIKEY Authentication Server will try to identify the application from which the request for registration
came. A client component record must exist for the provisioning application and location from which it con-
nects to the server. The component type is set as a parameter by the application; the location is the source IP
address of the SOAP request.
Note
A client component with an IP address range (IPv4 CIDR notation) as component location will be used to handle
IDENTIKEY Authentication Server 3.20 – Product Guide 123
5. Software DIGIPASS Provisioning
requests from any client within that IP address range. If two (or more) matching client components with over-
lapping IP address ranges are found, the client component with the smaller IP address range (more specific)
takes precedence and will be used to serve the request.
Identify Policy
IDENTIKEY Authentication Server identifies the policy to use in the registration from the client component
record and checks the validity of the policy. The following settings of the policy will not be used as they are
not relevant to provisioning.
n DIGIPASS assignment settings
n Challenge settings
DIGIPASS user account Lookup and Checks
IDENTIKEY Authentication Server checks the user account to:
n Ensure that the user account and domain have been defined
n Perform the Windows Group Check if necessary
n Check whether a user account exists
n Check whether the user account is disabled or locked if it already exists.
If the DIGIPASS user account is locked, IDENTIKEY Authentication Server verifies whether a user auto-
unlock attempt is possible (see 10.5. DIGIPASS User Account Auto-Unlock).
Local Authentication
A static password or one-time password must be entered. For more information about local authentication
options and their implications on the user authentication process during software DIGIPASS provisioning, see
5.1.6. User Authentication during Provisioning
If back-end authentication is not enabled, the registration will fail if:
n Static password is not verified
n User account does not exist
n User account exists but has no password recorded against it
If back-end authentication is enabled, then the back-end system will verify the static password. If the pass-
word is verified but there is no user account in IDENTIKEY Authentication Server, an account will be created.
Dynamic User Registration must be enabled for this to succeed.
Note
User authentication during software DIGIPASS provisioning may vary depending on the local authentication policy
settings, and on whether the user already has an activated DIGIPASS authenticator. For more information, see
IDENTIKEY Authentication Server 3.20 – Product Guide 124
5. Software DIGIPASS Provisioning
5.1.6. User Authentication during Provisioning.
Back-End Authentication
Back-end authentication is an optional step in software DIGIPASS registration. If enabled, the static password
will be authenticated by the back-end system. If the back-end system does not verify the credentials, regis-
tration will fail.
DIGIPASS Assignment
The registration process will perform the following steps:
n Search for an applicable DIGIPASS according to the criteria on the policy associated with the user account
that is capable of activation.
n If no DIGIPASS authenticator was found, the first applicable and available DIGIPASS record is assigned to
the user account.
Activation Code Generation
The reactivation restrictions are checked. If this is a reactivation and reactivation is allowed, then the user
account and the DIGIPASS record already exist in IDENTIKEY Authentication Server and will be used in the fol-
lowing steps.
The activation code is generated using the first capable application in the DIGIPASS. The activation code may
be encrypted with the user's password if the password was not verified by local and back-end authentication.
If defined in the effective policy, the DIGIPASS start time is calculated and set based on the delayed activation
period. If defined, notifications are scheduled to be sent to the respective user when (a) the delayed activ-
ation begins and (b) the DIGIPASS start time has been reached and the DIGIPASS authenticator becomes act-
ive.
Finalization
In the finalization step the created users and assignment are confirmed to the data store. Records are written
to the audit system to record the actions that have taken place, and the results. A response is sent to the user
to confirm registration or to show an error message if activation failed.
Note
For information specific to the registration process in the Multi-Device Licensing and Activation Mode, refer
to Section 5.2.2. Multi-Device Activation .
5.4. Software DIGIPASS Activation Process
The following diagram summarizes the activation process for Software DIGIPASS:
IDENTIKEY Authentication Server 3.20 – Product Guide 125
5. Software DIGIPASS Provisioning
Image 46: Software DIGIPASS Activation Process
Identify component, policy and DIGIPASS user account lookup and checks
The activation process performs the same Identify Policy and DIGIPASS user account lookup and checks as
the registration process, except that the user account must already exist.
Verify one-time password
The one-time password is verified against the DIGIPASS record.
Activation
The DIGIPASS is set to ACTIVE in the data store and the grace period will end, if one was set.The grace period
automatically expires the first time an OTP is used to log in, i.e. after the OTP has been successfully validated
(if it has not been set manually to expire prior to that in the relevant policy).
Finalization
In the Finalization step the activation is confirmed to the data store. Records are written to the audit system
to record the actions that have taken place, and the results. A response is sent to the user to confirm activ-
ation or show an error message if activation failed.
Note
For information specific to the registration process in the Multi-Device Licensing and Activation Mode, refer
IDENTIKEY Authentication Server 3.20 – Product Guide 126
5. Software DIGIPASS Provisioning
to Section 5.2.2. Multi-Device Activation .
5.4.1. Software DIGIPASS Reactivation
From time to time software DIGIPASS will have to be reactivated. This may occur rarely for Mobile Authenticator Stu-
dio, such as when the user buys a new mobile phone, or it may occur more often for DIGIPASS for Web, such as
when the user clears the cookies in their browser.
Reactivation is carried out in the same way as the original activation, but the user account will already exist with a
capable DIGIPASS assigned. The registration process will use the assigned DIGIPASS to generate the activation
code.
The following limits can be enabled via IDENTIKEY Authentication Server Configuration Utility:
n Activation Limit: limits the number of activations that can be performed on one Software DIGIPASS.
n Minimum Interval: sets the minimum time interval between reactivations.
n Maximum Locations: sets the maximum number of locations a from which a Software DIGIPASS can be
activated, such as home, office, laptop. This only applies to DIGIPASS for Web.
Note
The activation limits apply to all activation attempts. If an activation fails in the second stage this will still count
as an activation, and will count against the activation limits.
IDENTIKEY Authentication Server 3.20 – Product Guide 127
6. DIGIPASS Authentication for Windows Logon
6. DIGIPASS Authentication for Windows Logon
DIGIPASS Authentication for Windows Logon provides strong authentication when logging on to Microsoft Win-
dows. In this type of authentication, a user logs on to Microsoft Windows using:
n User ID
n Password
n one-time password generated by a DIGIPASS authenticator
n Server PIN
The credentials used by DIGIPASS Authentication for Windows Logon are either validated directly by IDENTIKEY
Authentication Server (online authentication) or using offline authentication data generated by IDENTIKEY Authentic-
ation Server (offline authentication). Whether DIGIPASS Authentication for Windows Logon performs an online or an
offline authentication depends on the availability of the IDENTIKEY Authentication Server instance and is com-
pletely transparent to the user.
The DIGIPASS Authentication for Windows Logon consists of a client software package, which is installed on the cli-
ent computer, and server-side functionality, which is part of IDENTIKEY Authentication Server. DIGIPASS Authentic-
ation for Windows Logon requires a valid license to enable it on IDENTIKEY Authentication Server.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that for being GDPR-com-
pliant, DIGIPASS Authentication for Windows Logon requires the Verify server SSL certificate box to be checked in
the DIGIPASS Authentication for Windows Logon Configuration Center.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
6.1. Additional References
n DIGIPASS Authentication for Windows Logon Product Guide
n DIGIPASS Authentication for Windows Logon Getting Started Guide
n DIGIPASS Authentication for Windows Logon User Guide
6.2. Online Authentication
Online authentication occurs when a user authenticates to Microsoft Windows using DIGIPASS Authentication for
Windows Logon while the client computer is connected to the network and can establish a connection to
IDENTIKEY Authentication Server. Authentication is performed using IDENTIKEY Authentication Server in real time.
IDENTIKEY Authentication Server 3.20 – Product Guide 128
6. DIGIPASS Authentication for Windows Logon
Image 47: DIGIPASS Authentication for Windows Logon Online Authentication
The user ID, password (optional), and one-time password (OTP) are sent to IDENTIKEY Authentication Server to be
verified. If the OTP credentials are valid, DIGIPASS Authentication for Windows Logon receives the static Windows
user password from IDENTIKEY Authentication Server and uses it to authenticate to Microsoft Windows.
If offline authentication is enabled, IDENTIKEY Authentication Server also sends (encrypted) offline authentication
data to DIGIPASS Authentication for Windows Logon. Offline authentication data is used for offline authentication
when no connection to IDENTIKEY Authentication Server can be established.
DIGIPASS Authentication for Windows Logon and IDENTIKEY Authentication Server communicate via SOAP using
HTTPS.
6.3. Offline Authentication
Offline authentication occurs when a user authenticates to Microsoft Windows using DIGIPASS Authentication for
Windows Logon while the client computer is not connected to the network or cannot establish a connection to
IDENTIKEY Authentication Server. Authentication is performed using (locally stored and encrypted) offline authen-
tication data.
The offline authentication data is generated by IDENTIKEY Authentication Server during successful online authen-
tication. Offline authentication data is either limited to a specific time span (time-based) or a number of authen-
tications (event-based), thus requiring the client to perform online authentication regularly.
Offline authentication needs to be enabled via the IDENTIKEY Authentication Server configuration.
IDENTIKEY Authentication Server 3.20 – Product Guide 129
6. DIGIPASS Authentication for Windows Logon
Image 48: DIGIPASS Authentication for Windows Logon Offline Authentication
The user ID, password (optional), and one-time password (OTP) are authenticated using the offline authentication
data. The authentication result is then sent back to DIGIPASS Authentication for Windows Logon on the client com-
puter. The offline authentication data can be used a limited number of times, and that limit can be configured
using the Administration Web Interface.
DIGIPASS Authentication for Windows Logon checks whether:
n Offline authentication data is available for the user. Offline authentication data is generated after a suc-
cessful online authentication when offline authentication is enabled in the relevant DIGIPASS Authentic-
ation for Windows Logon client component policy.
n This offline authentication data is still valid. Offline authentication data is valid for a limited time for time-
based data, or a limited number of logons for event-based data. The time or event limit is defined in the
relevant DIGIPASS Authentication for Windows Logon client component policy.
n The OTP validation succeeds with the offline authentication data.
Note
Although a user can have more than one DIGIPASS authenticator assigned, only the first one ever used with
DIGIPASS Authentication for Windows Logon has offline authentication data assigned. If the user attempts an off-
line authentication using another DIGIPASS authenticator with no offline authentication data assigned, DIGIPASS
Authentication for Windows Logon will display an authentication error.
If you need to switch offline authentication data support to another DIGIPASS authenticator, reset the offline
authentication data for the currently used DIGIPASS authenticator in the Administration Web Interface and per-
form an online authentication using the other DIGIPASS authenticator immediately afterward.
Note
It is also possible to configure user-specific policy settings for offline authentication. These settings will override
those set by the parent policy. For more information, refer to 13.2. User-Specific Authentication Policy Overrides.
IDENTIKEY Authentication Server 3.20 – Product Guide 130
6. DIGIPASS Authentication for Windows Logon
6.3.1. Disabling Offline Authentication
When offline authentication is disabled for a user, be aware of the following:
n Disabling offline authentication for a user means that IDENTIKEY Authentication Server will not send any
new encrypted offline logon data to the client computer.
n Disabling offline authentication for a user means that the user will still be able to use offline authen-
tication from the time that it is disabled until the encrypted offline logon data expires OR until the user per-
forms the next online authentication.
6.3.2. Forcing Static Password Verification
You can enforce static password verification during offline authentication via DIGIPASS Authentication for Windows
Logon, by disabling Stored Password Proxy and setting Back-End Authentication to Always.
6.3.3. Forcing OTP Use
A user may be forced to log on either online or offline using OTP by configuring DIGIPASS Authentication for Win-
dows Logon accordingly. For more information, refer to the DIGIPASS Authentication for Windows Logon User
Guide, Section "Enforcing DIGIPASS authentication".
6.3.4. Backup Offline Authentication for DIGIPASS Authentication for Windows Logon
You can use Primary Virtual Mobile Authenticator as a backup solution for DIGIPASS Authentication for Windows
Logon offline authentication. This extends the OTP delivery features of Message Delivery Component to DIGIPASS
Authentication for Windows Logon.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that for being GDPR-com-
pliant, DIGIPASS Authentication for Windows Logon requires the Verify server SSL certificate box to be checked in
the DIGIPASS Authentication for Windows Logon Configuration Center, and the SEAL protocol used for com-
munication with IDENTIKEY Authentication Server must be SSL enabled in the Message Delivery Component Con-
figuration Utility.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
Backup offline authentication is intended as a temporary backup login solution. If offline authentication is enabled
in the used IDENTIKEY Authentication Server policy, IDENTIKEY Authentication Server sends encrypted offline
authentication data (for offline authentication with the primary DIGIPASS authenticator) and backup offline
IDENTIKEY Authentication Server 3.20 – Product Guide 131
6. DIGIPASS Authentication for Windows Logon
authentication data (for backup offline authentication with Primary Virtual Mobile Authenticator) to the DIGIPASS
Authentication for Windows Logon client during successful online authentication; during backup offline authen-
tication, the DIGIPASS Authentication for Windows Logon client verifies OTPs against the backup offline authen-
tication data.
Backup offline authentication requires that users have assigned both a DIGIPASS authenticator for online and off-
line authentication, and Primary Virtual Mobile Authenticator for backup offline authentication. To generate
(backup) offline authentication data, users must successfully complete at least one online authentication pro-
cedure using DIGIPASS Authentication for Windows Logon.
Warning
Backup offline authentication will not work with Backup Virtual Mobile Authenticator.
6.4. Dynamic Component Registration (DCR)
Dynamic Component Registration (DCR) is used by DIGIPASS Authentication for Windows Logon 1.x to register a
component for use when logging on to Microsoft Windows using a one-time password (OTP). DIGIPASS Authentic-
ation for Windows Logon requires a client component to be registered for a user at the IP address used. DCR
checks to see if a client component for that IP address exists for a user, and if not it creates one.
Note
Dynamic Component Registration (DCR) is only supported for DIGIPASS Authentication for Windows Logon 1.x.
The Windows Logon client component is identified by the following formats:
n Client machine hostname: If a DNS-based reverse lookup of an IP address is being used with the DNS suf-
fix not set on the client machine.
n Fully qualified domain name (FQDN): If a DNS-based reverse lookup of an IP address is being used with
the DNS suffix set.
Using Windows Group Check, IDENTIKEY Authentication Server can test for Microsoft Windows groups of client com-
puters on a network. These groups can be used to define which computers on a network can use DIGIPASS
Authentication for Windows Logon, thus allowing a gradual and controlled implementation.
For more information about Dynamic Component Registration, refer to the DIGIPASS Authentication for Windows
Logon Product Guide.
6.5. Password Randomization
DIGIPASS Authentication for Windows Logon can be configured to provide password randomization. With password
randomization, the Windows logon password is generated in the background, with a randomized password format-
ted according to strict formatting rules.
IDENTIKEY Authentication Server 3.20 – Product Guide 132
6. DIGIPASS Authentication for Windows Logon
With password randomization, the user logs on by entering only the user ID, OTP, and (optionally) a Server PIN,
with the password generated in the background. Using password randomization prevents a user from logging on
to Windows using a client computer which does not have DIGIPASS Authentication for Windows Logon installed.
After a successful authentication towards the IDENTIKEY Authentication Server, password randomization replaces
the static password used to authenticate the Windows client to the Windows domain with a randomly-generated
static password. This randomly-generated password is no longer known to the user, thereby forcing the user to
use DIGIPASS OTP authentication.
Note
For Active Directory deployments with password randomization enabled, a new random password will be gen-
erated again once Active Directory indicates that the password is about to expire.
The randomly-generated password remains constant in the IDENTIKEY Authentication Server user account record,
and a corresponding attribute is added to trace randomization status.
Configuring password randomization requires:
n LDAP or Windows back-end authentication towards Active Directory
n Password Randomization to be enabled in the policy
Note
If the Password Randomization feature of IDENTIKEY Authentication Server is used, the policy used in IDENTIKEY
Authentication Server must not apply password proxying for the changeBackendPassword SOAP com-
mand because this would lead to a user with a randomized password being able to change their password.
6.6. Password Synchronization Manager
Password Synchronization Manager (PSM) is a product that is installed on the domain controller which allows a
change of the Windows password to be automatically updated on IDENTIKEY Authentication Server. The new Win-
dows password will be reflected as the static password on IDENTIKEY Authentication Server.
When the Windows password is changed, it is updated on the domain controller. PSM checks for the availability of
IDENTIKEY Authentication Server before sending the new password to IDENTIKEY Authentication Server so that the
data store can be updated.
If IDENTIKEY Authentication Server is not available the synchronization will fail.
If the user is not defined on IDENTIKEY Authentication Server, only the password on the domain controller will be
changed.
For more information, refer to the Password Synchronization Manager User Guide.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), you need to secure the
IDENTIKEY Authentication Server 3.20 – Product Guide 133
6. DIGIPASS Authentication for Windows Logon
communication between Password Synchronization Manager and IDENTIKEY Authentication Server via SSL to be
GDPR-compliant. Each IDENTIKEY Authentication Server configuration can be updated to use encrypted com-
munication via the Use SSL option in the password filter configuration of the PSM Remote Configuration
Manager.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
IDENTIKEY Authentication Server 3.20 – Product Guide 134
7. EMV-CAP
7. EMV-CAP
EMV-CAP is the Chip Authentication Program (CAP) developed by credit card leaders Europay, Mastercard, and Visa
(EMV). OneSpan provides a range of smart card readers, which are EMV-CAP–compliant.
Image 49: DIGIPASS 810
7.1. Hardware Security Module
A Hardware Security Module is highly recommended for use with EMV-CAP smart card readers (see 8.2. Licensing
and Configuration).
7.2. EMV-CAP Scenario
The EMV-CAP scenario must be enabled in the configuration of each IDENTIKEY Authentication Server before EMV-
CAP functionality is available. For more information, refer to the Configuration Utility Help or the IDENTIKEY
Authentication Server Administrator Reference, Section "Configuration".
7.3. Licensing
These licensing options must be included for each IDENTIKEY Authentication Server:
n HSM
n EMV-CAP
IDENTIKEY Authentication Server 3.20 – Product Guide 135
7. EMV-CAP
7.4. Unsupported Standard IDENTIKEY Authentication Server Features
The following standard features of IDENTIKEY Authentication Server are not supported with EMV-CAP:
n Dynamic User Registration
n Auto-Assignment
n Self-Assignment
7.5. Primary Account Number (PAN)
Whenever Primary Account Number (PAN) fields are displayed on the Administration Web Interface or the Con-
figuration Utility, they will be masked. Certain administrators will have an additional administrative permission
which will enable them to see PANs in clear text.
PANs will be stored as encrypted numbers on the data store. When the numbers are displayed they are decrypted
and then masked.
7.6. EMV-CAP modes
IDENTIKEY Authentication Server supports three EMV-CAP–compliant DIGIPASS applications, or modes. All modes
provide a secure code as output, but differ in the type of input data:
Table 7: Supported EMV-CAP modes in IDENTIKEY Authentication Server
Mode Data sent to IDENTIKEY Authentication Mandatory? Secure Code
Server
Mode 1 Challenge, transaction amount, or transaction NO Secure Code
currency
Mode 2 (Transaction Data Signing) Nine different data fields NO Signature
Mode 3 (Challenge/Response) Challenge YES Secure Code
IDENTIKEY Authentication Server 3.20 – Product Guide 136
8. Hardware Security Module
8. Hardware Security Module
A Hardware Security Module (HSM) may be integrated with IDENTIKEY Authentication Server to provide an extra
layer of security to data storage.
8.1. Supported Hardware Security Modules
IDENTIKEY Authentication Server supports the following Hardware Security Module models:
n Thales nShield Connect (Red Hat Enterprise Linux 6, 64-bit (x86_64))
n Thales nShield Solo (Red Hat Enterprise Linux 6, 64-bit (x86_64))
n SafeNet ProtectServer External 2
n SafeNet ProtectServer Internal Express 2
n SafeNet ProtectServer Internal Express
The Thales nShield Connect and Thales nShield Solo HSMs are supported with IDENTIKEY Authentication Server run-
ning on a 64-bit (x86_64) version of Red Hat Enterprise Linux 6. For more information about using either HSM, see
8.9. Thales nShield HSM.
If you plan to integrate IDENTIKEY Authentication Server with a supported Hardware Security Module, this HSM
must be installed and functioning correctly prior to IDENTIKEY Authentication Server installation.
8.2. Licensing and Configuration
To use HSMs, all instances of IDENTIKEY Authentication Server involved must be licensed for Hardware Security
Modules.
Connection and encryption settings for IDENTIKEY Authentication Server to use with the Hardware Security Module
(s) are configured during installation.
8.3. HSM Modules
To use either a SafeNet or Thales nShield Hardware Security Module with IDENTIKEY Authentication Server, the
appropriate VACMAN Controller HSM module must be installed. OneSpan provides the corresponding modules
required by both supported HSM brands.
For information about installing the appropriate VACMAN Controller HSM module, refer to the IDENTIKEY Authentic-
ation Server Administrator Guide, Chapter "Hardware Security Module (HSM)".
The HSM module for SafeNet ProtectServer is also referred to as functionality module (FM) as it serves as a third-
party module extending functionality in the HSM.
IDENTIKEY Authentication Server 3.20 – Product Guide 137
8. Hardware Security Module
The HSM module for Thales nShield is also referred to as SEE Module. For more information, see 8.9.3. SEE Mod-
ule.
8.4. HSM Migration
In the course of upgrading IDENTIKEY Authentication Server, it is possible to migrate from an SSM to an HSM install-
ation, and to migrate encrypted keys to the HSM. The Configuration Wizard will display the HSM Migration page
with options to select if an HSM is to be used and to specify the HSM type. If migration of the HSM is selected, the
pages to configure the HSM library and keys will be displayed. Once the connection to the HSM library is estab-
lished, the keys can be configured in IDENTIKEY Authentication Server. To effectively migrate to HSM, start rotation
from SSM to HSM keys in the IDENTIKEY Authentication Server Administration Web Interface. Only when the rota-
tion is finished, will the migration from SSM to HSM be completed.
For more information, refer to the IDENTIKEY Authentication Server Installation Guide for Linux or Installation Guide
for Windows (as applicable), Section "Configuring IDENTIKEY Authentication Server (Upgrade)".
Note
Migrating to an HSM installation is only possible if an SSM has been configured, and if the storage used is an
ODBC storage.
8.5. Unsupported Standard IDENTIKEY Authentication Server Features
When using HSMs with IDENTIKEY Authentication Server, certain standard features are not supported and certain
limitations apply.
The following standard features are not supported with HSMs:
n OATH-based authenticators
n Offline Data Generation (for Windows Logon)
n Active Directory Storage
The following RADIUS protocols are not supported with HSMs:
n CHAP
n MSCHAP
n MSCHAP2
8.6. Load Balancing and Failover
IDENTIKEY Authentication Server provides load-balancing and failover between Hardware Security Module slots.
IDENTIKEY Authentication Server 3.20 – Product Guide 138
8. Hardware Security Module
8.6.1. Session Pool
When the VASCO IDENTIKEY Authentication Server service or daemon is started, IDENTIKEY Authentication Server
will automatically create a Session Pool for use in accessing each HSM. HSM slots with an attribute matching the
IDENTIKEY Authentication Server configuration setting slotSelectionAttribute will be added to the Session Pool – up
to the value of the slotsExpected configuration setting.
When IDENTIKEY Authentication Server needs to access data protected by the HSM(s), it takes a random session
from the pool. Where multiple HSMs are available, this spreads the load across all slots.
If a session does not receive a response from a slot, the HSM is blacklisted and slots on the other HSM(s) will be
used, where available.
When using Thales nShield HSMs, load-balancing and failover are managed by the hardserver. For more inform-
ation, refer to 8.9. Thales nShield HSM
8.6.2. HSM Re-Initialization
IDENTIKEY Authentication Server will stop and re-initialize all HSMs in the Session Pool when:
n All configured HSMs are blacklisted, or
n At least one HSM has been blacklisted and no sessions are currently required
8.7. Cryptographic Keys
A Hardware Security Module can be used to protect and manage your high-value cryptographic keys. HSMs provide
stronger authentication for server applications. For more information on Hardware Security Modules, refer to Sec-
tion 8. Hardware Security Module . Cryptographic keys are used to encrypt four types of data:
n Storage data
n Sensitive data
n Transport keys
n Audit data (when Secure Auditing is enabled)
Storage data cryptographic keys are used for securing DIGIPASS BLOBs. Each DIGIPASS Application for each
DIGIPASS device has its own BLOB. This BLOB contains DIGIPASS configuration and other important information
about the device.
Audit data cryptographic keys are used for encrypting audit entries when secure auditing is enabled. For more
information, refer to 23.3. Secure Auditing.
Sensitive data keys are used for all other types of data.
IDENTIKEY Authentication Server 3.20 – Product Guide 139
8. Hardware Security Module
Transport keys are used to decrypt DIGIPASS import files (.dpx files). Such files are protected by double-DPX encryp-
tion, which provides extra security to DIGIPASS records prior to importing.
Note
If you are using a Thales nShield HSM with IDENTIKEY Authentication Server, the protection type for all Sensitive
Data Keys, Storage Data Keys, and Secure Auditing Keys must be set to module (as opposed to softcard or
token). When using the generatekey command, this is accomplished by using the protect=module
parameter.
Access to sensitive data, storage data, and audit data can be protected by the keys, which can be rotated at reg-
ular intervals, providing even greater security. To rotate the keys a job must be initiated from the Administration
Web Interface. The job can be scheduled or run immediately.
Note
When copying, migrating, or backing up encrypted database files, ensure that the encryption key (and/or the
optional password key) is also backed up. Otherwise, you will not be able to read the data, as it will be encryp-
ted.
The key rotation process involves decrypting data with an old encryption key, then re-keying the data with a new
encryption key. Rotating one sensitive data key affects all other sensitive data keys, while rotating a storage data
key affects all other storage data keys.
Cryptographic key rotation can take some time. You can schedule a key rotation to run at a convenient time, then
cancel it if not finished when system resources are needed again. If you restart the key rotation later, processed
data does not need to be re-processed.
With SafeNet HSMs, each slot contains a token. Multiple cryptographic keys can be stored in each token, as illus-
trated below:
IDENTIKEY Authentication Server 3.20 – Product Guide 140
8. Hardware Security Module
Image 50: SafeNet Cryptographic Keys Allocated by Token Name and Slot ID
8.8. SafeNet HSMs
In order to set up SafeNet HSMs to work with IDENTIKEY Authentication Server, you need to set up the following
components:
Software
The following software must be installed on the HSM:
n Version 2.07 or higher of the SafeNet ProtectServer firmware
Administrator Account
The setup process requires administration privileges in at least one administration token and one user token
on the Hardware Security Module.
Functionality Module (FM)
Setting up a SafeNet HSM involves copying the VACMAN Controller functionality module file—aal2sdk—to the
machine which will be used for HSM administration. The VACMAN Controller functionality module file may be
unsigned or signed, depending on your requirements. OneSpan provides both a signed and an unsigned
VACMAN Controller functionality module (refer to the IDENTIKEY Authentication Server Administrator Guide,
Section "Installing a SafeNet Hardware Security Module").
IDENTIKEY Authentication Server 3.20 – Product Guide 141
8. Hardware Security Module
8.9. Thales nShield HSM
IDENTIKEY Authentication Servernow supports the Thales nShield Solo and Thales nShield Connect, both of which
are Thales nShield Hardware Security Modules. At present, Thales nShield hardware security modules are sup-
ported with IDENTIKEY Authentication Server running on a 64-bit (x86_64) version of Red Hat Enterprise Linux 6.
Using a Thales nShield HSM with IDENTIKEY Authentication Server will require the following:
n Security World
n SEE Module
n Hardserver
8.9.1. Limitations in the usage of Thales nShield HSMs
n When using a Thales nShield HSM, the EMV-CAP feature of IDENTIKEY Authentication Server is not sup-
ported.
8.9.2. Security World
Security World is a Thales nShield-specific term that refers to the framework that controls access to and usage of
valuable cryptographic keys. A client application must first connect to a specific HSM belonging to a Security World
in order to connect to that Security World. In turn, access control to a Security World is configured in each HSM
within that Security World.
A Security World consists of the following:
n Thales nShieldHSMs
n Cryptographic keys: in the Security World, these keys are stored in an external file system. These keys are
all encrypted by a Security World Master Key, which is only stored in the HSM itself.
n Operator Card Set (OCS): this is a set of smart cards used to control access to Thales nShield HSM applic-
ation keys. When using an Thales nShield HSM with IDENTIKEY Authentication Server, the OCS is only
required for the initial setup of the Security World.
For information on the creation and usage of an OCS, refer to the Managing card sets and soft cards chapter in the
nShield Connect and netHSM User Guide.
For information on how to set up a Security World, refer to the Creating and managing a security world chapter of
the nShield Connect and netHSM User Guide. This guide is available in PDF format, packaged with your Thales
nShield HSM.
Note
IDENTIKEY Authentication Server supports both FIPS level 2 and FIPS level 3; however, we recommend the use of
IDENTIKEY Authentication Server 3.20 – Product Guide 142
8. Hardware Security Module
FIPS level 3 when setting up a Security World. When configuring a Security World to use FIPS level 3 with
IDENTIKEY Authentication Server, an OCS card should be permanently inserted into each HSM integrated with
IDENTIKEY Authentication Server.
8.9.3. SEE Module
OneSpan provides a Secure Execution Engine (SEE) Module to be used with Thales nShield HSMs. The SEE Module
contains custom firmware which allows Thales nShield HSMs to load and manage keys provided and used by
VACMAN Controller.
For instructions on how to install the SEE Module , refer to the Thales nShield HSMs section of the IDENTIKEY
Authentication Server Linux Installation Guide.
8.9.4. Hardserver
The hardserver (also known as nFastServer) is a Thales nShield client daemon that mediates communication
between the HSMs inside the Security World and IDENTIKEY Authentication Server. This daemon facilitates the fol-
lowing HSM tasks:
n Failover and disaster recovery
n Load balancing between multiple HSMs
n Loading cryptographic keys into the HSMs
n Loading DIGIPASS storage and transport keys into the SEE Module
When using supported Thales nShield HSMs with IDENTIKEY Authentication Server, the hardserver must be con-
figured to automatically:
n Connect to each Thales nShield HSM used with IDENTIKEY Authentication Server
n Load the SEE Module provided by IDENTIKEY Authentication Server into each HSM
In some cases, the server hosting the hardserver may also need to be configured to load the hardserver upon star-
tup.
For instruction on how to configure the hardserver to work with IDENTIKEY Authentication Server, refer to the
IDENTIKEY Authentication Server Linux Installation Guide.
IDENTIKEY Authentication Server 3.20 – Product Guide 143
9. Administration
9. Administration
This chapter provides a high-level overview of administration user accounts and all available administrative inter-
faces in IDENTIKEY Authentication Server.
9.1. IDENTIKEY Authentication Server Administrator Accounts
IDENTIKEY Authentication Server offers a number of different administrative user accounts:
n First administrator
Administrative account created during the installation of IDENTIKEY Authentication Server; has the full set
of administrative privileges of available scopes.
n Global administrator
After IDENTIKEY Authentication Server has been installed, the first administrator can assign privileges to
global administrators who are not restricted by domain, and can read and/or write data regardless of the
domain to which they belong. Global administrator accounts are created in the master domain, but the
administrative privileges assigned to them apply throughout all domains.
n Delegated administrator
Administrators created on domains other than Master. Their administration privileges only extend to their
respective domain scopes.
n Upgrade administrator
Upgrade administrators are assigned the new administrative privilege introduced with the new IDENTIKEY
Authentication Server version of the upgrade.
n Service user
Service users are a set of specific users required in the context of automated IDENTIKEY Authentication
Server administration workflows.
The scopes of an administrator can include:
n Master Domain
n All Domains including Master Domain
n Single domain
n Multiple domains excluding Master Domain
n Organizational unit
IDENTIKEY Authentication Server 3.20 – Product Guide 144
9. Administration
9.2. List of Administration Interfaces in IDENTIKEY Authentication Server
IDENTIKEY Authentication Server provides a range of interfaces to make administration tasks rapid and easy. The
following interfaces are readily available from the main IDENTIKEY Authentication Server menu:
n Configuration Utility
n Maintenance Wizard
n Administration Web Interface
n Active Directory Users and Computers Extension (Active Directory only)
n MDC Configuration Utility
n User CGI Configuration
n Audit Viewer
n Tomcat Monitor
n Tcl Command-Line Administration
The best administration interface to use in any particular situation will depend on the tasks required, and the data
store used by IDENTIKEY Authentication Server.
User/ DIGIPASS Administrator
The main tools you will use in managing users and DIGIPASS accounts are:
n Active Directory Users and Computers Extension (Active Directory only)
n Tcl Command-Line Administration
n Configuration Utility
n Administration Web Interface
System Administration
The main tools you will use for system administration are:
n Configuration Utility
n Audit Viewer
n Maintenance Wizard
9.3. Administration for Active Directory and ODBC
With an ODBC database data store (including the embedded MariaDB database), the Administration Web Interface
will be the main interface for most administrative functions. With an Active Directory data store, the Active Dir-
ectory Users and Computers Extension is used for managing DIGIPASS user account and DIGIPASS records, with
other tasks largely administered via the Active Directory Users and Computers Extension.
The following table outlines the different administrative tasks available for both interfaces, depending on the data
store used.
IDENTIKEY Authentication Server 3.20 – Product Guide 145
9. Administration
Table 8: Active Directory Users and Computers Extension vs Administration Web Interface
Data Store Active Directory Users and Computers Extension Administration Web Interface
ODBC N/A DIGIPASS users
DIGIPASS
Policies
Clients
Back-End Servers
Organization
Reports
Systems
Active Directory DIGIPASS users Policies
Clients
DIGIPASS Back-End Servers
Reports
Systems
9.4. Administration Web Interface
The Administration Web Interface is a web-based administration tool used for managing IDENTIKEY Authentication
Server. It can be opened in a browser window with an IDENTIKEY Authentication Server administrator user ID and
password. Click any of its top-level tabs to view and edit data, configure system settings, run reports, and more.
Note
Only Administrators should have access to the Administration Web Interface.
The homepage of the Administration Web Interface provides quick links to managing the DIGIPASS and user set-
tings, and provides information on the IDENTIKEY Authentication Server status. This information also includes the
time, date, and location (i.e. the IP address) of the last successful administrative log-on of the administrator cur-
rently logged in.
Image 51: Administration Web Interface
IDENTIKEY Authentication Server 3.20 – Product Guide 146
9. Administration
DIGIPASS Records and User Accounts Administration
The Administration Web Interface features several ways to add, remove, and manage users along with their
corresponding DIGIPASS; it also allows you to search for DIGIPASS user account records in a number of ways:
n Search directly by entering the user ID or DIGIPASS serial number
n Search for the user that a specific DIGIPASS belongs to by searching for the DIGIPASS and double clicking
on the user on the DIGIPASS details screen
n Enter the first few characters of the user ID followed by a wildcard (*). A results list will be provided from
which you can select the user required.
n Search for DIGIPASS that belong to a user by searching on the user and then double clicking on the
DIGIPASS on the User Details Screen.
n Enter the first few numbers of the DIGIPASS serial number followed by a wildcard (*). This will provide you
with a list from which you can select the DIGIPASS you require.
n You also can search based on the description field of a DIGIPASS record.
If IDENTIKEY Authentication Server uses an ODBC database—including the embedded MariaDB database—
as its data store, the Administration Web Interface can be used for a number of different administration tasks.
The Administration Web Interface facilitates the following tasks:
n Import DIGIPASS and DIGIPASS user accounts individually or in bulk
n Create DIGIPASS records and DIGIPASS user accounts
n Edit DIGIPASS user account
n Reset PIN for a DIGIPASS
n Assign and unassign DIGIPASS
n Disable DIGIPASS user account
n Delete DIGIPASS user account
n Activate and deactivate applications for DIGIPASS
n Manage, activate, and deactivate DIGIPASS licenses and instances
n Add custom and/or RADIUS user attributes, individually or in bulk
n Unlock a DIGIPASS
n Mobile Authenticator Studio DIGIPASS management including:
n Generate Activation data
n Send Activation data
n Bind Device
n Unbind Device
Note
DIGIPASS instances that have been generated from a DIGIPASS license cannot be assigned to or unassigned from
the user. For more information about DIGIPASS instances and licenses and the Multi-Device Licensing and Multi-
Device Activation features of IDENTIKEY Authentication Server, see 2.4. DIGIPASS Licensing and Activation.
Other Major Administrative Tasks
The Administration Web Interface can also be used to create, edit, or delete the following:
IDENTIKEY Authentication Server 3.20 – Product Guide 147
9. Administration
n Policy records (new policy records can also be created using a wizard)
n Client records
n Back-end server records; the Administration Web Interface can also be used to configure general back-
end authentication settings
n Domains or organizational units
In addition, the Administration Web Interface can also be used to perform the following major administrative
tasks:
n Run existing reports and to create new reports (see 14. Reporting).
n From the Servers tab, you can manage various scheduled tasks including cryptographic data rotation,
migrate data after an IDENTIKEY Authentication Server upgrade, and manage and list administrative ses-
sions.
n The System tab allows you to administer the system. From here, you can add or remove IDENTIKEY
Authentication Server instances, administer the license, and configure the IDENTIKEY Authentication
Server.
9.5. Active Directory Users and Computers Extension
The Active Directory Users and Computers Extension allows administration of DIGIPASS user account and records
within the Active Directory Users and Computers interface.
Note
The Active Directory Users and Computers Extension is only available where Active Directory is utilized as the
data store.
The extension adds context menu options, user property sheet tabs and a property sheet for the DIGIPASS records,
as outlined in the following sections.
Connection
No logon screen is presented by the extension; an implicit logon to Active Directory will be carried out using
your current Windows user context. It will connect to the same domain controller as the Active Directory Users
and Computers connection.
The extension will make its own LDAP connection to Active Directory. Administration does not take place via
the IDENTIKEY Authentication Server. Your administrative permissions will depend on the permissions that
your Active Directory user account has within Active Directory.
When do new settings take effect?
When settings are changed with the extension, the new values may not always take effect immediately. For
more information, refer to the Active Directory Replication Issues in the IDENTIKEY Authentication Server
Administrator Guide.
IDENTIKEY Authentication Server 3.20 – Product Guide 148
9. Administration
9.5.1. Context Menu Extensions
The Active Directory Users and Computers Extension adds OneSpan-specific context menu options on the following
containers in the tree pane:
n The Users container
n All organizational units
n The Digipass-Pool, Digipass-Reserve and Digipass-Configuration containers
9.5.2. User Property Sheet Extensions
The Active Directory Users and Computers Extension also adds the following tabs to the property sheet of a user
record:
n DIGIPASS user account tab: contains extra information about the DIGIPASS user account required by
IDENTIKEY Authentication Server. This includes settings such as authentication policy overrides, and the
date and time that a DIGIPASS user account was created.
n DIGIPASS Assignment tab contains information on all DIGIPASS assigned to the DIGIPASS user. These
DIGIPASS can be administered from this tab, including unassignment or enabling Backup Virtual Mobile
Authenticator. DIGIPASS may also be assigned to the DIGIPASS user from this tab.
n Provisioning tab contains features related to the distribution and special administration of software
DIGIPASS and DIGIPASS 110.
9.5.3. DIGIPASS Record Administration
DIGIPASS information may be viewed via the property sheet of its assigned user, or by turning on Advanced
Features. Provided that you have the required permissions, enabling Advanced Features will allow you to see
DIGIPASS records wherever they are located in Active Directory (typically in the DIGIPASS-Pool container if unas-
signed), view properties and use a number of context menu actions.
For more details on these actions, refer to 11. DIGIPASS.
The context menu of the DIGIPASS record contains options for bulk management. The property sheet for the
DIGIPASS record shows full details of the DIGIPASS and all its Applications and enables all administration tasks for
the record.
Search for DIGIPASS Records
The Active Directory Users and Computers Extension allows you to search for specific DIGIPASS records, or
DIGIPASS records meeting a search criteria. This functionality can be useful when you have DIGIPASS records
in various places throughout Active Directory.
IDENTIKEY Authentication Server 3.20 – Product Guide 149
9. Administration
9.6. Tcl Command-Line Administration
Tcl Command- Line Administration allows interactive command- line and scripted administration of DIGIPASS
related data. It has a number of possible uses:
n Interactive command-line administration
n Scripted administration
n Complex bulk administration tasks
n Reporting on the data in the data store
It is an extension of the Tcl scripting language, and administrators will require a basic competence in Tcl in order to
use the command-line utility.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that the
dpadmincmd.xml configuration file must be configured to enable the SSL parameter.
For more information on GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regulation
Compliance Guide.
The Tcl Command-Line Administration consists of the following components:
DPADMINCMD
This is a command-line program that can be used interactively or called from within a batch file, script or
other program. This provides a command shell based on the Tcl interpreter.
OneSpan Tcl Extension Library
The main functionality is provided by the OneSpan extensions to Tcl. This provides a set of additional com-
mands in a OneSpan namespace.
Tcl Runtime
The IDENTIKEY Authentication Server installation program also installs the Tcl runtime environment, which is
necessary to run DPADMINCMD.
Tip
Windows command-line functions may be run from within the Tcl Command-Line Administration. A new Win-
dows command-line console may also be opened.
IDENTIKEY Authentication Server 3.20 – Product Guide 150
9. Administration
9.7. Configuration Utility
IDENTIKEY Authentication Server uses a local XML text file for various configuration settings. This can be admin-
istered using a graphical user interface, referred to as Configuration Utility.
Note
Some settings within the IDENTIKEY Authentication Server XML configuration file can also be changed via the
Administration Web Interface.
To run the Configuration Utility on Windows, navigate to:
Start > Programs > VASCO > IDENTIKEY Authentication Server > IAS Configuration Utility
To run the Configuration Utility on Linux, open a terminal window and run ikconfigutilgui.
Note
You need root privileges to run the Configuration Utility. Running the Configuration Utility without root privileges
will fail with a "Permission denied" message.
IDENTIKEY Authentication Server 3.20 – Product Guide 151
9. Administration
Image 52: Configuration Utility
Whenever you use the Configuration Utility to change any settings, IDENTIKEY Authentication Server needs to be
restarted before the new settings take effect. The Configuration Utility will perform the restart when you exit.
The Configuration Utility controls the following setting groups:
n General: Server location, RADIUS dictionary file path, and Tracing.
n Communicators: SOAP, RADIUS, and SEAL communication protocols, including SSL.
n Scenarios: Available scenarios depend upon your license agreement.
n Engines: Defines your back-end authentication plug-in engines.
n Storage: Add and configure additional ODBC databases.
n Auditing: Enable/Disable audit methods.
n Replication: Specify replication settings.
n Server Discovery: optional DNS service registration.
n Performance: Enable/Disable Performance Monitoring filters and plugins.
IDENTIKEY Authentication Server 3.20 – Product Guide 152
9. Administration
Warning
The Configuration Utility of IDENTIKEY Authentication Server contains settings relevant to the GDPR.
For more information on a GDPR-compliant setup of IDENTIKEY Authentication Server, refer to the IDENTIKEY
Authentication Server General Data Protection Regulation Compliance Guide.
For more information on these setting groups, refer to the IDENTIKEY Authentication Server Configuration Settings
section of the IDENTIKEY Authentication Server Administrator Reference.
9.8. Configuration Wizard
The IDENTIKEY Authentication Server Configuration Wizard provides two different modes:
Installation Wizard
The Configuration Wizard runs in the Installation Wizard mode when launched during the installation or
upgrade process. When the IDENTIKEY Authentication Server Setup Utility finishes installing all the necessary
components, it will display the Select Components screen. If you want to configure IDENTIKEY Authentication
Server immediately (recommended), click Run Installation Wizard to launch the Installation Wizard .
The Installation Wizard configures all the necessary settings to get the IDENTIKEY Authentication Server oper-
ational as easily and as intuitively as possible. The Configuration Wizard uses this mode if the IDENTIKEY
Authentication Server configuration file (identikeyconfig.xml) does not exist or is not valid for the current ver-
sion (as during an upgrade).
Maintenance Wizard
If the IDENTIKEY Authentication Server configuration file is present and valid for the current version, the Con-
figuration Wizard will run in the Maintenance Wizard mode.
This mode allows you to perform a couple of maintenance tasks that are not available in the day-to-day
administration tools:
n Re-running the Installation Wizard
n Changing the server component location.
n Installing SSL server certificates
n Importing/exporting audit messages
n Rescuing the administrator account (i.e. creating a new administrator account)
n Rescuing the administration client (i.e. creating or modifying an administration program client)
n Restoring default policy and report definitions
n Exporting key data
n Changing key token PINs (only available if IDENTIKEY Authentication Server is using a SafeNet HSM)
For more information about the particular tasks, refer to the IDENTIKEY Authentication Server Administrator Guide,
Section "IDENTIKEY Authentication Server Configuration".
IDENTIKEY Authentication Server 3.20 – Product Guide 153
9. Administration
9.9. Other Administration Interfaces
IDENTIKEY Authentication Server also features the following administration interfaces:
Audit Viewer
Use the Audit Viewer to view Audit Messages. Audit messages consist of warnings and errors generated by
IDENTIKEY Authentication Server.
OneSpan Web Configuration Tool
The OneSpan Web Configuration Tool can be used to configure the Administration Web Interface and the
OneSpan User Websites. It allows you to configure:
n The list of IDENTIKEY Authentication Server instances which may be administered from the Administration
Web Interface
n SSL certificates for the Administration Web Interface and OneSpan User Websites
n The selection which product is configured: the Administration Web Interface, User Self-Management Web-
site, or Virtual Mobile Authenticator OTP Request Website.
Tomcat Monitor
The Apache Tomcat Monitor can be used to view and edit Tomcat settings, including:
n logon accounts
n log paths
n Java settings
n startup and shutdown details
User CGI Configuration
The DIGIPASS User CGI Configuration window manages:
n Primary Server Settings
n Backup Server Settings
n Connection Settings
n Tracing Settings
9.10. Task Scheduling
IDENTIKEY Authentication Server allows you to schedule selected tasks to run at specific times. Certain tasks can
be scheduled to run either immediately, or on a specified time and date. You can also schedule recurring tasks for
running reports. These can be scheduled to recur on a daily or monthly basis.
IDENTIKEY Authentication Server 3.20 – Product Guide 154
9. Administration
The configuration wizards in the Administration Web Interface feature a Schedule Task page. This page allows you
to define this schedule for each task and to set a task schedule as a recurring event.
For each scheduled task, you can set the required time and date; details for scheduled tasks are kept in the data
store. The tasks will run at the scheduled date and time, and audit messages are generated for the relevant start,
end, and result transactions. You can also configure your preferred notification method: IDENTIKEY Authentication
Server can send you a text message or an e-mail notification when the scheduled task is completed.
The Task Scheduling page in the Administration Web Interface lists all scheduled tasks. To view and edit sched-
uled tasks, you need the View Task administrative privilege.
9.11. Administration with Multiple IDENTIKEY Authentication Server Instances
In environments with multiple IDENTIKEY Authentication Server instances, administrative tasks such as user and
DIGIPASS import or reporting can be handled in two different ways, depending on the database and replication
setup of your system.
If you are using an ODBC-compliant database as the data store and commercial replication between database serv-
ers is configured, any IDENTIKEY Authentication Server instance can handle administrative tasks, with admin-
istration requests being spread between the server instances via a load balancer. No dedicated administration
server is required.
With Active Directory as the data store, and/or with IDENTIKEY Authentication Server replication enabled, you need
to set up a dedicated IDENTIKEY Authentication Server instance for administrative purposes, to reduce load on the
server instance(s) processing authentication requests.
For an overview of deployment models with multiple IDENTIKEY Authentication Server instances, refer to the
IDENTIKEY Authentication Server Performance and Deployment Guide.
9.12. Automating IDENTIKEY Authentication Server Administration Workflows
When working with custom integrations using the IDENTIKEY Authentication Server SDK, you can automate certain
administration workflows by creating automated IDENTIKEY Authentication Server services. This may be relevant if
you want to perform frequent administrative tasks on a large scale and you want to avoid creating and keeping
track of multiple active administrative sessions.
To achieve this, automated IDENTIKEY Authentication Server services require a special user for performing admin-
istrative requests, i.e. the service user. Service users do not log on interactively to components such as Admin-
istration Web Interface, but authorize each administrative operation individually via the API key generated by
IDENTIKEY Authentication Server. This API key can be provided either within the the sessionID SOAP field, or
the HTTP Authorization header.
IDENTIKEY Authentication Server 3.20 – Product Guide 155
9. Administration
To automate administrative tasks, you need to first create a service user and generate an API key in the Admin-
istration Web Interface.For details on the service user and API key authorization, refer to the IDENTIKEY Authentic-
ation Server Administrator Guide.
Once the service user is in place, you need to add the service user's credentials to the sessionID SOAP field for
each command, or to the HTTP Authorization header. For more information, refer to the IDENTIKEY Authentication
Server SDK Programmer's Guide for Java or the IDENTIKEY Authentication Server SDK Programmer's Guide for .NET.
IDENTIKEY Authentication Server 3.20 – Product Guide 156
10. DIGIPASS User Accounts
10. DIGIPASS User Accounts
All users requiring authentication by IDENTIKEY Authentication Server must have user records registered in
IDENTIKEY Authentication Server in order to:
n Assign DIGIPASS authenticators to users
n Store user-specific parameters
n Store user attributes
n Assign privileges
n Overrule policy settings at user level
User accounts can be created, managed, and searched for using the Administration Web Interface.
10.1. Creating DIGIPASS User Accounts
A DIGIPASS user account can be created using the Administration Web Interface in the following ways:
n Importing users from a file, single records or in bulk. For more information, refer to the Administration Web
Interface Help, "How To Import Users".
n Manually creating user records using Create User in the Administration Web Interface. For more inform-
ation, refer to the Administration Web Interface Help, "How To Create a User".
n Dynamically during authentication processing (if Dynamic User Registration is enabled).
n Via LDAP synchronization. User information on IDENTIKEY Authentication Server can be synchronized with
external LDAP databases by using the LDAP Synchronization Tool. For more information, refer to the LDAP
Synchronization Tool Guide.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that LDAP Syn-
chronization Tool is used to synchronize user information from any LDAP data store with any IDENTIKEY
Authentication Server data store. To be GDPR-compliant, the following requirements must be met:
n Secure version of LDAP (LDAPS) is used.
n SEAL protocol used for communication with IDENTIKEY Authentication Server is SSL enabled.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection
Regulation Compliance Guide.
10.1.1. Creating a DIGIPASS User Account Using Dynamic User Registration (DUR)
When IDENTIKEY Authentication Server receives an authentication request for a user without a DIGIPASS user
account, it can check the credentials with the back-end server (e.g. Windows ). If back-end authentication is suc-
cessful, IDENTIKEY Authentication Server can create a DIGIPASS user account automatically for the user. This pro-
cess is called Dynamic User Registration (DUR) and can be enabled via policy.
IDENTIKEY Authentication Server 3.20 – Product Guide 157
10. DIGIPASS User Accounts
Dynamic User Registration (DUR)
Dynamic User Registration (DUR) allows to create a DIGIPASS user account automatically when the user cre-
dentials are validated using back-end authentication. The correct static password is sufficient to permit a
DIGIPASS user account to be created.
DUR is commonly used together with Auto-Assignment; with this combination, new accounts are immediately
assigned to a DIGIPASS. For more information about Auto-Assignment, see 11.2.2. Auto-Assignment.
DUR user information synchronization
DUR user information synchronization allows IDENTIKEY Authentication Server to retrieve user information
when a DIGIPASS user account is created using DUR with an LDAP back-end server, by synchronizing the data
from the LDAP back-end server to the respective DIGIPASS user account data fields. The user information that
can be retrieved includes the user display name and contact data, such as the mobile phone number and the
email address. The LDAP attributes used to query the respective user information are configurable.
By default, DUR user information synchronization is disabled. To enable and configure it, you need to change
the applicable policy accordingly.
Case-Sensitivity and User ID/Domain Conversion
If the data store is case-sensitive and the IDENTIKEY Authentication Server has not been configured to convert
user IDs and domains to upper or lower case, it is possible for multiple DIGIPASS user accounts to be created
for a single user. For example, if a user logs in with jsmith on one occasion, and JSmith on another,
two DIGIPASS user account may be created for both login attempts.
To avoid this:
n if the underlying user accounts are Windows user accounts, enable Windows Name Resolution in the Con-
figuration Utility. For more information, refer to the IDENTIKEY Authentication Server Administrator Guide,
Section "Domains and Organizational Units". This is highly recommended.
n Alternatively, you can also configure the IDENTIKEY Authentication Server to convert all user IDs and
domains to upper or lower case. For more information, refer to the IDENTIKEY Authentication Server Admin-
istrator Guide, Section "Encoding and Case-Sensitivity".
10.1.2. Creating a DIGIPASS User Account Using LDAP User Synchronization
LDAP user synchronization supports automatic creation and updating of user accounts on the IDENTIKEY Appliance
from records stored on one or more LDAP servers. Synchronization needs to be configured in the Configuration
Tool, by defining a synchronization profile for your specific LDAP server(s).
IDENTIKEY Authentication Server 3.20 – Product Guide 158
10. DIGIPASS User Accounts
10.2. Changes to Stored Static Passwords
If Stored Password Proxy is enabled, any changes to a user's password on a back-end system need to be com-
municated to the IDENTIKEY Authentication Server. This can be done using Password Autolearn.
If Password Autolearn is enabled, a user may directly log in with their new static password in front of their OTP. If it
does not match the static password stored by the IDENTIKEY Authentication Server, it can be verified with the
back-end authenticator. If correct, the IDENTIKEY Authentication Server will store the new static password for
future use and authenticate the user. For more information, refer to 3.7.3. Password Autolearn.
10.3. Password Strength
10.3.1. What Are Password Strength Rules?
You can customize password strength rules to enhance password security. These rules control the required format-
ting of passwords. Password strength rules are configurable in the policy associated with the IDENTIKEY Authentic-
ation Server component. The password strength rules can be configured via the User tab in the Administration Web
Interface policy administration page. Different password complexity rules can be applied for administrators and
users.
n Administrators. IDENTIKEY Authentication Server supports password complexity rules through the server
policy. There is a client component entry per server in the database, which has a policy assigned. The
effective policy values for password complexity rules are applied for administrator users.
n Users. When applying password complexity rules to users (i.e. no administrative privileges assigned), only
the values defined in the base policy of the server policy are applied, instead of the effective settings.
By default, password complexity rules are only defined in the base policy, i.e. a default installation of IDENTIKEY
Authentication Server will have to be adapted accordingly.
Note
The user password strength rules for administrative programs or clients that will connect to IDENTIKEY Authentic-
ation Server are defined in the server policy. Password policies only apply to static passwords when they need to
be created or updated. They do not apply to the passwords used by the following:
n First administrator
n SSL certificates
n Security configuration for the initial SNMPv3 user
For these the default password rules apply.
The variables that can be configured are:
n Minimum password length
n Minimum number of lower case characters
IDENTIKEY Authentication Server 3.20 – Product Guide 159
10. DIGIPASS User Accounts
n Minimum number of upper case characters
n Minimum number of numeric characters
n Minimum number of symbols
n Password different from the number of passwords previously used
n Specify the number of passwords that must be used before you can reuse a password
n No inclusion of part of the user ID
n Whether or not the user ID (or parts thereof) may be used in the password
Note
IDENTIKEY Authentication Server supports Unicode in passwords, however support of characters can be
limited by the back-end server, should one have been configured to be used in the respective context.
For more information, refer to the IDENTIKEY Authentication Server Administrator Reference, Section "Policy Prop-
erties" .
10.3.2. Password Strength Rules Enforcement
Password strength rules are ALWAYS enforced in the following circumstances:
n During the first installation of an ODBC system.
n If a user is created or updated, or if a password is set using the Administration Web Interface or the Tcl
Command-Line Administration tool.
The default password strength rules will be applied to the first administrator password. The default password
strength rules are:
n At least 7 characters long
n Contains at least 1 lowercase character
n Contains at least 1 uppercase character
n Contains at least 1 numeric character
Password strength rules are NOT enforced for users in Active Directory installations.
For back-end authentication with ODBC, the password policy of both IDENTIKEY Authentication Server and back
end should be identical. If there are multiple back ends with each one having different password policies, the
IDENTIKEY Authentication Server should be either less strict or just as strict as the least strict password policy
among all the back ends.
10.3.3. Static Password Expiration (Local Password)
Another factor contributing to password strength is the expiration of the static password as this ensures that end
users change their static password at adequate intervals. In IDENTIKEY Authentication Server the end user's local
static password continuously expires at the interval that has been specified, and if the local authentication mode
DIGIPASS or Password has been selected in the effective policy. For more information about this authentication
mode, see 3.6. Local Authentication.
IDENTIKEY Authentication Server 3.20 – Product Guide 160
10. DIGIPASS User Accounts
Note that this type of password expiration applies to the static password locally stored in IDENTIKEY Authentication
Server. If you change the local static password, it is not synchronized with the static password in a possible back-
end system. That means that if you are using back-end authentication, the local static password and the back-end
password will be different, for example, after changing the local password via the Administration Web Interface.
Note
You should not use local static password expiration when using back-end authentication, but rely on the back-
end system to enforce password expiration (see 10.3.4. Static Password Expiration (Back-End Password)).
If Days to Notify before Expiration has been set in the effective policy, the user will receive a notification in
IDENTIKEY Authentication Server and/or OneSpan User Websites that the static password is about to expire with
the exact expiration date indicated.
Web Administration Service allows users to set their passwords when they are notified and have the respective
administrative privileges (Set User Password).
10.3.4. Static Password Expiration (Back-End Password)
Usually you can configure your back-end passwords to expire to force users to change their back-end passwords
regularly. This is preferred to using local password expiration (see 10.3.3. Static Password Expiration (Local Pass-
word)).
If you configure your static back-end passwords to expire after a certain time, you can allow users who log on to
the Administration Web Interface to change their password right from the login page. This means that whenever a
user attempts to log on to the Administration Web Interface and the back-end password has expired or has been
set to be changed at next logon, the user is automatically redirected to a change password page.
In order to set a new back-end password, the user needs to authenticate first using either the current back-end
password or a one-time password (OTP) generated by an authenticator assigned to the user. In the former case,
the user is automatically logged on after successfully setting a new back-end password; in the latter case, the
user is redirected to the login page again.
Changing expired back-end passwords at the login page requires the following:
n The authentication scenario must be enabled.
n The effective policy must have back-end authentication set to Always.
n If you have enabled Stored Password Proxy in the policy to use the stored password for back-end authen-
tication, you must enable Password Autolearn as well. Otherwise, the stored password and the effective
back-end password will differ after changing an expired back-end password and logon will no longer
work.
IDENTIKEY Authentication Server 3.20 – Product Guide 161
10. DIGIPASS User Accounts
10.4. Administration Privileges
Administration of data in an ODBC database is performed through IDENTIKEY Authentication Server to control the
administrator's access to data.
Administrative permissions may be assigned based on:
n Type of permission (e.g. Read, Create)
n Type of object (e.g. DIGIPASS, policy)
The domain and organizational unit in which the administrator account is located will determine their range of
administration access:
n If the account belongs to an organizational unit, the administrator will be able to administer user accounts
and DIGIPASS records belonging to that organizational unit.
n If the account does not belong to an organizational unit, the administrator will be able to administer all
DIGIPASS records and user accounts in the domain to which they belong.
n If the account belongs to the Master Domain, the administrator may be able to administer all DIGIPASS
records and user accounts in the database. This depends on the Access Data in All Domains privilege,
which is only available to administrators in the Master Domain.
For ODBC deployments, you can configure a user's Administration Privileges via the Administration Web Interface.
For Active Directory deployments, you can configure Administration privileges via the Active Directory Users and
Computers Extension .
Administrators may also be limited to assigning only privileges which they possess themselves .
For more information, refer to the IDENTIKEY Authentication Server Administration Privileges section of the
IDENTIKEY Authentication Server Administrator Reference.
10.4.1. Restrictions to User IDs with Administration Privileges
For security purposes, user IDs with administration privileges may be restricted from performing certain non-admin-
istrative tasks, such as authentication or signing transactions. These restrictions can be configured on the Users
section in the Policy tab of the Administration Web Interface.
Users with an Administrative Privileges field can be set to:
n Allow the user ID to continue into the non-administrative transaction, where the usual rules will then apply
to determine success or failure
n Prevent the User ID from progressing to any non-administrative processing.
These restrictions protect user IDs with administration privileges from being locked out due to too many failed
authentications.
IDENTIKEY Authentication Server 3.20 – Product Guide 162
10. DIGIPASS User Accounts
Warning
If the privileges of an administrator are changed while that administrator is logged in to the Administration Web
Interface, the updated privileges will not affect that administrator's current session. Rather, the updated priv-
ileges will take effect on that administrator's next login.
10.4.2. Duplication of Administrative Privileges
You can copy administrative privileges from one user to any number of users in one transaction via the Copy Admin
Privileges From wizard. This wizard makes the administrative privileges of two users identical; this means that if a
recipient user has privileges that the source user does not have, then the recipient user will lose those privileges.
Note
Copy Admin Privileges From does not copy the domain scope along with the Administrative Privileges. Domain
scope values must be set per administrator.
10.5. DIGIPASS User Account Auto-Unlock
A DIGIPASS user account can become locked after a specified number of unsuccessful authentication attempts.
Unlocking a locked DIGIPASS user account usually requires assistance from an administrator.
To ease unlock effort and reduce support incidents, you can allow users to unlock a locked DIGIPASS user account
themselves without administrative assistance using user auto-unlock.
10.5.1. Basic Concepts
The user auto-unlock mechanism allows a user to implicitly unlock a locked DIGIPASS user account during regular
authentication or signature validation. It is enabled and configured using policies.
Note
For security reasons user auto-unlock works only, if the DIGIPASS user account has been locked after too many
consecutively failed authentication attempts. A DIGIPASS user account that has been explicitly locked by an
administrator cannot be unlocked by the user auto-unlock mechanism.
When a DIGIPASS user account becomes locked, it remains locked for a specified time span, i.e. the lock duration.
After that time span the user may try to authenticate again. If authentication succeeds the DIGIPASS user account
is unlocked at the same time. If authentication fails the DIGIPASS user account remains locked. The number of
maximum unlock attempts is limited; if no more unlock attempts are left, the DIGIPASS user account remains
locked and can only be unlocked by an administrator.
After each unsuccessful unlock attempt the effective lock duration is increased by a specified multiplier, thus
increasing the time span before the user may try to unlock the DIGIPASS user account again. Note that the effective
IDENTIKEY Authentication Server 3.20 – Product Guide 163
10. DIGIPASS User Accounts
lock duration is considered to begin from the last authentication request. Attempting to unlock by authenticating
(even with a valid password or OTP) before the lock duration has elapsed does not count as unlock attempt (and
does not unlock the DIGIPASS user account). However, since it is considered an (unsuccessful) authentication
request, the last authentication request time is updated, meaning that the lock duration begins again.
10.5.2. Configuration
By default, user auto-unlock is disabled. To enable and configure it, you need to change the applicable policy
accordingly. A default policy prepared to support user auto-unlock is included in the set of pre-loaded policies, i.e.
IDENTIKEY Local Authentication with Auto-Unlock . For more information, refer to the IDENTIKEY Authentication
Server Administrator Guide, section "DIGIPASS User Account Locking".
IDENTIKEY Authentication Server 3.20 – Product Guide 164
11. DIGIPASS
11. DIGIPASS
This chapter provides more details on the deployment and administration of DIGIPASS users, accounts, and
devices.
Note
The user can perform many DIGIPASS functions that are unavailable during a usual login for different reasons on
the User Self-Management Website and the Virtual Mobile Authenticator OTP Request Website. For more inform-
ation, refer to the OneSpan User Websites Administrator Guide.
11.1. Importing DIGIPASS
DIGIPASS records may be imported into IDENTIKEY Authentication Server via the Administration Web Interface .
DIGIPASS can be imported either individually or in bulk.
The DIGIPASS Import Wizard guides you through the steps of importing DIGIPASS from the .dpx file. You can specify
the applications that will be available with the imported DIGIPASS, and whether the imported DIGIPASS will be set
as Active or Inactive on import. You can also specify if existing DIGIPASS will be updated with the data from the
.dpx import file.
11.2. Assigning DIGIPASS to Users
DIGIPASS may be assigned to users in a number of ways, depending on the requirements of your company. For
example, a company with only a few user accounts may use Manual Assignment. A larger company needing to dis-
tribute large numbers of DIGIPASS may find it easier to simply distribute the DIGIPASS and require each user to go
through Self-Assignment.
For both assignment modes, a grace period is typically set, which allows a number of days in which the user may
still log in using only their static password. After the grace period has expired, depending on the Local Authentic-
ation settings in the relevant policy, users can then either continue to use both their static password or their
DIGIPASS authenticator (DIGIPASS or Password), or must only use the authenticator (DIGIPASS/Password during
Grace Period or Digipass Only) to log in. The grace period automatically expires the first time an OTP is used to log
in, i.e. after the OTP has been successfully validated (if it has not been set manually to expire prior to that in the rel-
evant policy). Refer to Sections 3.6. Local Authentication and 3.6.2.2. Grace Period for more information.
Note
DIGIPASS records must be imported into the data store before being assigned to users.
Resetting the Server PIN is also possible during DIGIPASS assignment. When using the DIGIPASS Self-Assignment or
Auto-Assignment feature of IDENTIKEY Authentication Server, the user can reset their Server PIN. When the Assign-
ment Mode is set to Self-Assignment-Pin-Reset or Auto-Assignment-Pin-Reset, the user's Server PIN is auto-
IDENTIKEY Authentication Server 3.20 – Product Guide 165
11. DIGIPASS
matically reset. This is an optional feature and does not require any administrator action, once the option has been
enabled in the DIGIPASS properties and/or the relevant policy settings have been set accordingly.
11.2.1. Self-Assignment
Users can assign a DIGIPASS device themselves via Self-Assignment. With this process, the user must log in and
include the serial number, static password, and one-time password. This informs the IDENTIKEY Authentication
Server of the assignment; provided that the user enters the details correctly, IDENTIKEY Authentication Server will
link the DIGIPASS record and the user account. A grace period is not used for this method.
Procedure 5: Self-Assignment Process
1. DIGIPASS user account is created manually by an administrator, or automatically by IDENTIKEY Authentic-
ation Server during Dynamic User Registration.
2. The DIGIPASS is sent to the user.
3. User receives the DIGIPASS.
4. User logs in using:
n DIGIPASS serial number
n Static password
n one-time password
5. IDENTIKEY Authentication Server recognizes Self-Assignment login.
6. IDENTIKEY Authentication Server verifies DIGIPASS serial number, static password, and one-time pass-
word.
7. IDENTIKEY Authentication Server assigns the DIGIPASS with the corresponding serial number to the user.
11.2.2. Auto-Assignment
With Dynamic User Registration, IDENTIKEY Authentication Server performs Auto-Assignment, where IDENTIKEY
Authentication Server will select a random DIGIPASS authenticator and assign it to the new DIGIPASS user account
as it is created. The DIGIPASS authenticator will then be delivered to the user.
Note
When maker–checker authorization is enabled, assigning a DIGIPASS authenticator requires the approval of a
checker administrator. In that case, Auto-Assignment is not available.
Procedure 6: Auto-Assignment Process
1. DIGIPASS user account is created automatically by IDENTIKEY Authentication Server during Dynamic User
Registration.
2. IDENTIKEY Authentication Server selects a random available DIGIPASS authenticator to prevent collisions
during parallel assignment of DIGIPASS authenticators.
3. IDENTIKEY Authentication Server assigns this DIGIPASS authenticator.
4. IDENTIKEY Authentication Server sets a grace period.
5. DIGIPASS is sent to the user.
6. User logs in with the static password during the grace period.
IDENTIKEY Authentication Server 3.20 – Product Guide 166
11. DIGIPASS
7. User receives the DIGIPASS.
8. User logs in with one-time password.
9. Grace period automatically ends.
11.2.3. Manual Assignment
With Manual Assignment, selected DIGIPASS devices are manually assigned to specific DIGIPASS user accounts.
The DIGIPASS must then be sent to the users.
Procedure 7: Manual Assignment Process
1. DIGIPASS user account is created manually by an Administrator, or automatically by IDENTIKEY Authentic-
ation Server during Dynamic User Registration.
2. The Administrator assigns a DIGIPASS to the user and sets a grace period.
3. DIGIPASS is sent to the user.
4. User logs in with static password during the grace period.
5. User receives DIGIPASS.
6. User logs in with one-time password.
7. Grace period is automatically ended.
11.3. DIGIPASS Record Functions
A number of functions are available to administer DIGIPASS records. These are typically required for
maintenance; for example, if a user has forgotten their Server PIN, or if a DIGIPASS has been locked.
11.3.1. Reset Application
A DIGIPASS Application may need to be reset if the time difference between the application and the server
needs to be recalculated. This would typically be for time-based Response-Only DIGIPASS after a very long
period of inactivity. The 'reset' widens the allowable time window for the next login, allowing the user to log
in and the IDENTIKEY Authentication Server to calculate the current time shift.
11.3.2. Set Event Counter
If the event count for an event-based application has become unsynchronized between the DIGIPASS and the
server, this function can be used to set the server event count to the event count on the DIGIPASS.
IDENTIKEY Authentication Server 3.20 – Product Guide 167
11. DIGIPASS
11.3.3. Enable/Disable Server PIN
An administrator may enable or disable use of a Server PIN with a specific DIGIPASS authenticator, or with mul-
tiple authenticators. If Server PIN is enabled, the user must include their Server PIN when logging in. If Server
PIN is disabled, the user must not include a Server PIN.
If a user’s Server PIN needs to be changed – usually because the user has forgotten it – then it can be reset,
and the user can create a new Server PIN when they next log in. This may be done when unassigning or re-
assigning a DIGIPASS.
11.3.4. Force PIN Change
This function can be used when an administrator wants a user to change their Server PIN on their next login.
This may be desirable as a security measure.
11.3.5. Set PIN
A user’s Server PIN can be set to a specific value and communicated to the user.
11.3.6. Unlock DIGIPASS
If a user incorrectly enters their DIGIPASS PIN into their DIGIPASS a predetermined number of times, the
DIGIPASS will become locked. Once locked, the assistance of an administrator will be required to unlock it.
This function allows an administrator to provide the user with an Unlock Code to enter into their
DIGIPASS.
Reset Error Count
When a user attempts to log in with incorrect details, the Error Count for the target DIGIPASS Application incre-
ments by 1. Depending on the policy settings, when the Error Count reaches a set threshold, the DIGIPASS
Application used may be locked out from usage by the policy. Use the Reset Error Count function to reset the
Error Count to 0.
11.3.7. Reset Application Lock Count
If a user has attempted to log in with incorrect details too many times, the DIGIPASS Application used may be
locked, depending on policy settings. This function can be used to reset the record status for the DIGIPASS
Application to the unlocked status. This differs from user locking, as the user may still log in with a different
IDENTIKEY Authentication Server 3.20 – Product Guide 168
11. DIGIPASS
DIGIPASS.
11.3.8. Reset Activation
Use this function to reset the Last Activation Date/Time, the Activation Location, and Activation Counter for a
DIGIPASS.
DIGIPASS Start Time
The DIGIPASS start time defines a particular date and time when an activated (software)
DIGIPASS authenticator can effectively be used for authentication. IDENTIKEY Authentication Server will not
allow the DIGIPASS authenticator to be used for authentication, until the start time has been reached.
DIGIPASS Expiration Time
The DIGIPASS expiration time defines a particular date and time when a DIGIPASS authenticator expires and
can no longer be used for authentication.
11.4. DIGIPASS Reports
IDENTIKEY Authentication Server comes with a wide variety of pre-set reports useful for managing and analyzing
DIGIPASS activity. These reports are available via the Administration Web Interface, and can track the following stat-
istics (among others):
n Assignment actions per user, organizational unit and domain
n Available DIGIPASS, sorted by type
n DIGIPASS deployment trends
n Breakdown of the number of deployed DIGIPASS per DIGIPASS type, sorted by organizational unit
n List of all DIGIPASS devices, and the last time they were used
n Inactive DIGIPASS (i.e. DIGIPASS that have not been used for more than six months)
For more information about reports, refer to Section 14. Reporting.
11.5. DIGIPASS Programming
This section enumerates the different DIGIPASS settings that can affect common administrative tasks.
IDENTIKEY Authentication Server 3.20 – Product Guide 169
11. DIGIPASS
11.5.1. DIGIPASS PIN
11.5.1.1. DIGIPASS Client PIN
A DIGIPASS may require a DIGIPASS PIN. If set, the PIN must be entered into the DIGIPASS before obtaining a one-
time password. This means that just possessing the DIGIPASS is not enough to log in to a network: the person log-
ging in must also know the DIGIPASS PIN.
DIGIPASS PIN settings include:
n An initial PIN can be set for a DIGIPASS device. This PIN must then be sent to the user of the DIGIPASS, typ-
ically separate from the DIGIPASS delivery.
n First Use PIN Modification requires a PIN change from the user upon the first use of the DIGIPASS device.
n PIN Change allows a user to change their PIN as desired.
n The PIN length can be set for a DIGIPASS device.
n DIGIPASS Lock sets the number of consecutive faulty PIN entries allowed before the DIGIPASS device is
locked.
Note
The DIGIPASS client PIN is not possible with one-button models (i.e. the DIGIPASS GO range models). The Server
PIN is an alternative solution for two-factor authentication only available with one-button DIGIPASS models. Refer
to Section 3.6.2.1. Server PIN for more information on the server PIN.
Also, each DIGIPASS authenticator may be given a grace period when it is assigned to a DIGIPASS user account. For
more information on this, refer to Section 3.6.2.2. Grace Period.
11.5.2. Time/Event-Based DIGIPASS Applications
The following table describes the time-based and event-based modes of different DIGIPASS Applications.
Table 9: Time-and event-based modes of DIGIPASS Application
DIGIPASS Application Time-Based Mode Event-Based Mode
Response-Only Changes the displayed OTP based on the current time. Displays a new OTP each time a request for an
The common time step used is 36 seconds: this means OTP is made.
that the OTP to be displayed will change every 36
seconds, whether or not an OTP has been requested
from the DIGIPASS.
Challenge/Response Generate an OTP based on the challenge given and the Generates an OTP based only on the challenge
current time. The common time step used is 9 hours ( given.
'slow challenge'). This would mean that if the exact same
challenge were given to a DIGIPASS within a 9- hour
period, the DIGIPASS Application will generate the same
OTP. However, challenges are very rarely repeated within
such a time period.
IDENTIKEY Authentication Server 3.20 – Product Guide 170
11. DIGIPASS
Table 9: Time-and event-based modes of DIGIPASS Application (continued)
DIGIPASS Application Time-Based Mode Event-Based Mode
Signature Generates a different signature for the same input data at Contains a numeric counter that increases every
different times. time a signature is generated.
A Signature DIGIPASS Application can also be neither time- nor event-based. Such DIGIPASS Applications will
always produce the same signature for the same input. There is no difference between real-time and deferred
time with such signatures.
11.5.3. OTP Length
This setting refers to the length of the one-time password generated by the DIGIPASS for Response-Only and Chal-
lenge/Response DIGIPASS Application.
Check Digit
A check digit may be added to each OTP. This is generated from the response and allows for faster inval-
idation of incorrect OTPs.
The OTP Length setting does not count the check digit.
11.5.4. Challenge Length
This setting refers to the length of the challenge which should be expected by the DIGIPASS. This is used by the
Challenge/Response DIGIPASS Application.
Check Digit
A check digit may be expected with each challenge. This is generated by the server from the challenge and
allows the DIGIPASS to reject most invalid challenges.
The Challenge Length does not count the check digit.
11.5.5. Signature Settings
Signature DIGIPASS Applications can be configured with the following settings:
n Signature Length: The length of the signature generated by the DIGIPASS.
n Signature Data Fields: The data fields that may be provided when signing a transaction. There may be
from 1 to 8 fields, each with a minimum length of 0 and a maximum length of 16.
n Check Digit: A check digit for transaction signatures (Signature Data Fields) is optional.
IDENTIKEY Authentication Server 3.20 – Product Guide 171
11. DIGIPASS
11.6. DIGIPASS Record Settings
These settings are kept in the record for a DIGIPASS Application, and affect which OTP is expected by the
IDENTIKEY Authentication Server.
11.6.1. Time/Event-Based DIGIPASS Record Settings
Time Step Used
The time step used by the DIGIPASS Application (see Section11.5.2. Time/Event-Based DIGIPASS Applications
).
Last Time Shift
Time Shift records any misalignments between the time recorded on the DIGIPASS and the time recorded on
the server each time a user logs in. This ensures that if either clock drifts from the correct time, an allowance
can be made by the IDENTIKEY Authentication Server; the user will then still be able to log in. If the time drift
goes beyond the allowable time window between user logins, the DIGIPASS record will have to be reset (this
allows for recalculation of the time drift).
Example
Time window may be 5 steps in either direction.
This means that 11 OTPs would be considered valid – the exact OTP for that time, and the OTPs for the 5
time steps either side of the exact time. If the OTP given is for a different time step, the time shift for that
DIGIPASS will be recorded. The next time the user logs in, the expected OTP will be calculated based on that
time shift.
Last Time Used
This records the time when the DIGIPASS Application was last used. If the amount of time lapsed between
authentications is greater than the expected time drift for the DIGIPASS, the time window is widened to allow
a greater number of one-time passwords to be accepted.
Last Event Value
The current number of uses of the DIGIPASS Application, according to the DIGIPASS. This can get out of sync
with the number of uses recorded by the IDENTIKEY Authentication Server when:
n Login failures occur for other reasons than incorrect OTP
n The DIGIPASS has been used without a login (eg. children have been playing with it)
n The DIGIPASS is being used to log in to two separate systems
IDENTIKEY Authentication Server 3.20 – Product Guide 172
11. DIGIPASS
The purpose of this setting is similar to that of Last Time Shift setting: it allows IDENTIKEY Authentication
Server to track any shifts between the event count recorded by itself and the DIGIPASS.
11.6.2. Backup Virtual Mobile Authenticator Settings
Several settings dictate how a user can use the Backup Virtual Mobile Authenticator feature. These settings are:
n Enable or disable Backup Virtual Mobile Authenticator and enable method (i.e. Required).
n Time limit/expiry (applies to Time Limited enable only)
n Maximum number of times a user may make use of the Backup Virtual Mobile Authenticator.
The above settings may be set both at the policy level and at the DIGIPASS record level. Individual settings override
policy settings for an individual DIGIPASS, but some policy settings (see below) may be used to automatically set
DIGIPASS settings which are blank when the Backup Virtual Mobile Authenticator is first utilized by the user.
Time Limit and Maximum Users per User
The following table lists Backup Virtual Mobile Authenticator policy settings and DIGIPASS settings relating to time
limits and maximum users:
Table 10: Backup Virtual Mobile Authenticator Policy/ DIGIPASS Settings
Policy Settings DIGIPASS Settings
Time Limit Enabled Until
Max. Uses/User Uses Remaining
If Backup Virtual Mobile Authenticator is enabled for a DIGIPASS and set to Time Limited, and the Enabled Until
field in the DIGIPASS property sheet is blank on their first use of the Backup Virtual Mobile Authenticator, the time
limit will begin counting on the user's first usage of the feature. The expiry date (today’s date + time limit) will
then be displayed in the Enabled Until field.
If a Max. Uses/User is set for the relevant policy and a DIGIPASS record's Uses Remaining field in their user property
sheet is blank on their first use of the Backup Virtual Mobile Authenticator, a number (Max Uses/User) will be auto-
matically entered into the user's Uses Remaining field and immediately decremented by 1.
Note
If a user has Backup Virtual Mobile Authenticator enabled with Enabled Until date set and their Uses Remaining
has been set (automatically or manually), whichever of these expires first will disable Backup Virtual Mobile
Authenticator for the user.
Example
Backup Virtual Mobile Authenticator is enabled for a user as Time Limited, and the server Time Limit setting is 3
IDENTIKEY Authentication Server 3.20 – Product Guide 173
11. DIGIPASS
days. The Max. Uses/User policy setting is 5. When the user first makes use of the Backup Virtual Mobile
Authenticator, his Enabled Until is set to a date 3 days hence and their Uses Remaining to 4.
During the next 48 hours, the user logs in 4 more times.
Although the user’s time limit does not run out for another 24 hours, their Uses Remaining is now 0, thereby dis-
abling Backup Virtual Mobile Authenticator .
11.6.3. Server PIN Settings
Server PIN refers to a PIN that the user enters into the login password field in front of the OTP displayed on the
DIGIPASS. This PIN is checked by the authenticating server. The DIGIPASS PIN, on the other hand, indicates a PIN
entered into a keypad on the DIGIPASS. This PIN is checked by the device itself, and is never transmitted to the
server.
Table 11: Server PIN Settings
Setting Explanation
PIN Supported Factory default built-in technology - controls whether a PIN must be included in a user's login.
PIN Change On Enables a user to change their Server PIN for this DIGIPASS device.
Force PIN Change Forces the user to change their Server PIN upon next login.
PIN Length The length of the current Server PIN.
PIN Minimum Length The minimum PIN length required by the server.
11.6.4. Factors to Consider When Implementing Virtual Mobile Authenticator
The following is a list of factors to consider when planning to integrate Virtual Mobile Authenticator into an authen-
tication service.
11.6.4.1. DIGIPASS Assignment Options
With the introduction of Virtual Mobile Authenticator, there are several different assignment combinations that can
be used. The first option in the table below does not utilize Virtual Mobile Authenticator. The others include a Vir-
tual Mobile Authenticator in either a Backup or Primary mode.
Table 12: DIGIPASS Options
Primary Backup Description
DIGIPASS None User must log in using a DIGIPASS.
DIGIPASS Backup Virtual User usually logs in using a DIGIPASS, but may utilize the Backup Virtual Mobile Authenticator
Mobile Authenticator feature where required. Usage of the feature may be limited.
IDENTIKEY Authentication Server 3.20 – Product Guide 174
11. DIGIPASS
Table 12: DIGIPASS Options (continued)
Primary Backup Description
DIGIPASS (tem- Backup Virtual User must log in using the Backup Virtual Mobile Authenticator feature. This might be used
porarily disallowed) Mobile Authenticator while a user’s DIGIPASS is lost, until the DIGIPASS is recovered.
Primary Virtual N/A User is assigned a Virtual Mobile Authenticator and must log in using it.
Mobile Authenticator
11.6.4.2. Cost
Your company will probably need to pay an amount for each text message sent. In some countries, mobile phone
owners might need to pay an amount for each text message received on their mobile phone. This will need to be
taken into consideration when deciding how to implement Virtual Mobile Authenticator functionality.
11.6.4.3. Security
The level of security provided by hardware DIGIPASS devices is higher than that of Virtual Mobile Authenticator. This
needs to be weighed against other considerations before deciding whether your company will implement Virtual
Mobile Authenticator, and if so, how it will be implemented.
11.6.4.4. Convenience
Virtual Mobile Authenticator is more convenient than a hardware DIGIPASS for many users. Virtual Mobile Authentic-
ator uses ordinary mobile phones (of which most users already own); there are no extra devices required. users
who do not habitually carry their mobile phone with them, though, are likely to find a DIGIPASS GO3 or DIGIPASS
GO1 easier to transport.
For users with Backup Virtual Mobile Authenticator enabled, it might be the difference between going to work to
pick up a forgotten DIGIPASS and getting important work done at home.
11.6.4.5. Gateway and account
Your company will need the use of an SMS gateway and an account with the gateway. The Message Delivery Com-
ponent will need configuration information for the gateway and the username and password for the account. Your
OneSpan supplier can assist with this process.
11.6.4.6. Backup Virtual Mobile Authenticator Usage Guidelines
The following questions will need to be answered in line with developing Backup Virtual Mobile Authenticator
usage guidelines:
n Will any users have access to Backup Virtual Mobile Authenticator?
n If so, will all users have access to Backup Virtual Mobile Authenticator?
n Will usage of Backup Virtual Mobile Authenticator be limited? If so, how?
n Time-limited?
n Limited number of uses?
IDENTIKEY Authentication Server 3.20 – Product Guide 175
11. DIGIPASS
Table 13: Backup Virtual Mobile Authenticator Sample Guidelines
Guideline Pro Con
Backup Virtual Mobile Authenticator disabled for all by default, Low text message Manual enable for each user and circumstance. Poss-
enabled for individual users as required. costs ible heavy administration load.
Backup Virtual Mobile Authenticator enabled for all, either Predictable text Administrator may need to reset limits frequently –
time/number of usage limit set. message costs medium administration load.
Backup Virtual Mobile Authenticator enabled for all - no limits set. Lighter admin- Possible high text message costs.
istration load
11.6.4.7. Virtual Mobile Authenticator Login Options
A decision must be made as to how users will log in using Virtual Mobile Authenticator. In particular, users with a
hardware DIGIPASS and the Backup Virtual Mobile Authenticator enabled must be able to request an OTP to be sent
to their mobile when required, but to login using the hardware DIGIPASS at other times.
The simplest method for the user is to allow a 2-step login process, where the user enters their user ID and pass-
word only, triggering an OTP request, and are redirected to a second login page to enter the OTP sent to them. To
use this method, though, your system must be set up to allow 2-step logins. Check with your system administrator
if unsure.
Alternatives to the 2-step login are a sequence of two 1-step logins or the use of a specific web page to request an
OTP, separate from the login page screen.
For more information, refer to the Login Permutations section of the IDENTIKEY Authentication Server Administrator
Reference.
11.6.4.8. Virtual Mobile Authenticator Usage Limitation
Use of Virtual Mobile Authenticator may be limited by:
n Using Backup Virtual Mobile Authenticator only.
n Minimizing the number of users assigned a Primary Virtual Mobile Authenticator.
When a user reaches his limit of Virtual Mobile Authenticator use, an administrator must reset that user's limit. A
user’s Primary Virtual Mobile Authenticator usage cannot be limited.
The Backup Virtual Mobile Authenticator feature may be enabled as an emergency backup for users who have left
their primary DIGIPASS at home, or for other reasons do not have access to their primary DIGIPASS. Use of this fea-
ture can be limited for each DIGIPASS by:
Time period
User access to Backup Virtual Mobile Authenticator can be set during a specific time period. After this period
expires, any Virtual Mobile Authenticator requests from the user will be rejected. If the user is still unable to
use their DIGIPASS, the time period must then be extended by an administrator. Once a user starts using his
DIGIPASS again, the administrator must reset the time period if the user is to be allowed to use Backup Virtual
Mobile Authenticator again.
IDENTIKEY Authentication Server 3.20 – Product Guide 176
11. DIGIPASS
Number of Uses
Set a maximum number of times a user may request an OTP using the Backup Virtual Mobile Authenticator
feature. When the user has reached this number of uses, any further OTP requests from the user will be rejec-
ted. This must be reset by an administrator if further use of the Backup Virtual Mobile Authenticator is
required for the user.
Global and Individual Backup Virtual Mobile Authenticator settings
Backup Virtual Mobile Authenticator options can be set globally or individually to allow a standard policy for all
DIGIPASS with exceptions made where necessary. Global settings will affect all DIGIPASS whose individual
option is set to Default.
Global options are defined in the policy that controls authentication. As such, using multiple policies provides
you with additional flexibility.
IDENTIKEY Authentication Server 3.20 – Product Guide 177
12. Components
12. Components
IDENTIKEY Authentication Server uses component records to determine which requests from which clients can be
processed. Component records also specify which policy should be used when processing requests. IDENTIKEY
Authentication Server uses server component records to represent IDENTIKEY Authentication Server instances.
12.1. Client Component Types
12.1.1. SOAP Client Programs
SOAP client programs are not called 'SOAP clients'. The program itself specifies the type as a parameter to each
request. A client component record must exist for this type at the location (IP address) where the application runs.
The policy in the component record will be used for all processing of requests from this client.
12.1.2. Administration Program
Creating a component record for a OneSpan administration program (e.g. Administration Web Interface or Audit
Viewer) allows a policy to be set for connections from that program.
A component record must exist for each Administration Web Interface or any other administration program using
SOAP and SEAL.
For the IDENTIKEY Authentication Server SEAL interface of the Tcl Command-Line Administration and the Audit
Viewer, the SEAL Require Administration Client Component Registration configuration setting determines whether
an administration program component must be provided or not.
12.1.3. IDENTIKEY User Websites
IDENTIKEY User Websites is a pre-defined SOAP-based client component used for OneSpan User Websites clients.
The client component record will be checked whenever the OneSpan User Websites client sends request to
IDENTIKEY Authentication Server.
One client component record must exist for each OneSpan User Websites client installed at different locations
(IP address). Each client component record requires a valid license key.
12.1.4. RADIUS Client
A RADIUS client component record is required when clients will be sending authentication requests to IDENTIKEY
Authentication Server using the RADIUS protocol. The IDENTIKEY Authentication Server will check the component
record to find:
IDENTIKEY Authentication Server 3.20 – Product Guide 178
12. Components
n the shared secret to use for communicating with the RADIUS client
n the policy to apply to the authentication request
A default RADIUS client component record is automatically created during installation of IDENTIKEY Authentication
Server. This can be deleted and specific records created for each location.
Note
The default RADIUS client created during installation will be given a shared secret by default.
12.1.5. DIGIPASS Authentication Module
A component record is required for any DIGIPASS Authentication Module used with IDENTIKEY Authentication
Server. The component record will be checked whenever the DIGIPASS Authentication Module sends an authen-
tication request to the IDENTIKEY Authentication Server. The IDENTIKEY Authentication Server will check:
n that the component record contains a valid license key for a client module
n which policy to apply to the authentication request
The following client types fall into this category:
n Citrix Web Interface (DIGIPASS Authentication for Citrix Web Interface)
n Outlook Web Access (DIGIPASS Authentication for OWA Basic and DIGIPASS Authentication for OWA Forms)
n IIS Module (DIGIPASS Authentication for IIS Basic)
n Windows Remote Desktop Web (DIGIPASS Authentication for Remote Desktop Web Access)
n SBR Plug-In (DIGIPASS Authentication for Steel-Belted RADIUS Server)
n Citrix Storefront (DIGIPASS Authentication for Citrix StoreFront)
n Microsoft ADFS (DIGIPASS Authentication for Microsoft ADFS)
n Epic Hyperspace (DIGIPASS Authentication for Epic Hyperspace)
12.1.6. DIGIPASS Authentication for Windows Logon
There are two pre-defined client components for DIGIPASS Authentication for Windows Logon:
n DIGIPASS Authentication for Windows Logon is a pre-defined SOAP-based client component used for
DIGIPASS Authentication for Windows Logon 2.x. Client component records of this type require a valid cli-
ent component license.
Client component records of this type are required for all client IP addresses used to log on to Windows via
DIGIPASS Authentication for Windows Logon 2.x. However, unlike DIGIPASS Authentication for Windows
Logon 1.x, you can define client component records to cover IP address ranges instead of individual client
component records for each individual IP address.
n Identikey Windows Logon Client is a pre- defined SEAL- based client component used for DIGIPASS
Authentication for Windows Logon 1.x. Client component records of this type do not require a client
IDENTIKEY Authentication Server 3.20 – Product Guide 179
12. Components
component license
A client component record of this type is required for each client IP address used to log on to Windows via
DIGIPASS Authentication for Windows Logon 1.x. DIGIPASS Authentication for Windows Logon 1.x uses
Dynamic Component Registration (DCR) to ensure that the correct client component record is available
when required (see 6.4. Dynamic Component Registration (DCR)).
Dynamic Component Registration (DCR) must be enabled in the Windows Logon policy.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that for being GDPR-com-
pliant, DIGIPASS Authentication for Windows Logon requires the Verify server SSL certificate box to be checked in
the DIGIPASS Authentication for Windows Logon Configuration Center.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
12.1.7. IDENTIKEY Federation Server
An IDENTIKEY Federation Server client component record for IDENTIKEY Authentication Server is required when
IDENTIKEY Federation Server is used for authentication to different Web applications. IDENTIKEY Federation Server
communicates with IDENTIKEY Authentication Server via the SEAL protocol. For more information about the func-
tionalities of and settings for IDENTIKEY Federation Server, refer to the IDENTIKEY Federation Server Product Guide.
Note
If you register IDENTIKEY Federation Server as a client, IDENTIKEY Authentication Server will require you to upload
a valid IDENTIKEY Federation Server license.
12.2. Server Components
A server component record holds the license key for a specific IDENTIKEY Authentication Server instance. This com-
ponent record will be checked when IDENTIKEY Authentication Server is started.
IDENTIKEY Authentication Server will check for:
n License key. If the license key is missing, invalid or expired, all authentication except for administration
logons will be refused. The following items need to be supported in the license key:
n RADIUS
n SOAP
n Authentication scenario
n Signature Validation scenario
n Provisioning scenario
n DIGIPASS Authentication for Windows Logon 1.x
IDENTIKEY Authentication Server 3.20 – Product Guide 180
12. Components
n Policy. The effective policy to use for SEAL administration logins. If an ODBC database (including the
embedded MariaDB database) is used as the data store, the policy will be applied to all administration
logins (including live audit connections) for which an administration program component record is not
found.
A server component record is automatically created for each IDENTIKEY Authentication Server instance during
installation.
IDENTIKEY Authentication Server 3.20 – Product Guide 181
13. Policies
13. Policies
Policies may be set up in a hierarchy, where a policy will inherit most of its attributes from a parent policy, but with
some modifications for a slightly different scenario. At the top of this hierarchy is a given parent or base policy - not
necessarily the default IDENTIKEY Authentication Server Base Policy - which does not inherit any attributes from
any other policies (i.e. parentless policies).
Image 53: Policy Inheritance Example
IDENTIKEY Authentication Server 3.20 – Product Guide 182
13. Policies
In the example above, all attributes are inherited from the parent policy. The attributes shown in the child policies
above are explicitly set, which make the policy different from the parent policy. The explicitly set attributes in the
child policies override those of the parent policies.
13.1. Show Effective Settings
As the various levels of settings in policy inheritance can get confusing, functionality is available which allows you
to view the settings effective for a selected policy, taking inherited settings into account. The text below shows the
effective settings for the IDENTIKEY Authentication Server RADIUS self-assignment policy:
Effective Policy Settings
[Local/back-end authentication]
Local Authentication : DIGIPASS/Password during Grace Period
back-end authentication : Always
Back-End Protocol : RADIUS
User Accounts]
Dynamic User Registration : Yes
Password Autolearn : Yes
Stored Password Proxy : Yes
Default Domain: (none)
User Lock Threshold : 3
[Windows Group Check]
Group Check Option : No Check
Group List: (none)
[DIGIPASS Assignment]
Assignment Mode : Self-Assignment
Grace Period (days) : 0
Serial No. Separator : |
Search up Organizational Unit Hierarchy : Yes
[DIGIPASS Settings]
Application Names
Application Type : No Restriction
DIGIPASS Types
PIN Changed Allowed : Yes
[1-Step Challenge Response]
Enabled : No
Challenge Length : 0
Challenge Check Digit : No
IDENTIKEY Authentication Server 3.20 – Product Guide 183
13. Policies
[2-Step Challenge Response]
Request Method : Keyword
Request Keyword
[Primary Virtual Mobile Authenticator]
Request Method : Password
Request Keyword
[Backup Virtual Mobile Authenticator]
Enabled : No
Maximum Days : 0
Maximum Uses : 0
Request Method : KeywordPassword
Request Keyword : otp
[Digipass Control Parameters]
Identification Time Window : 20
Signature Time Window:24
Event Window : 20
Initial Time Window : 6
Identification Threshold : 0
SignatureThreshold : 0
Check Challenge Flag : 1
Level of Online Signature : 0
Allowed Inactive Days : 0
The settings listed here include those set in policies from which the IDENTIKEY Authentication Server RADIUS Self-
Assignment policy inherits.
13.2. User-Specific Authentication Policy Overrides
Policies may be set up in a hierarchy, where a policy will inherit most of its attributes from a parent policy, but with
some modifications for a slightly different scenario. At the top of this hierarchy is a given parent or base policy - not
necessarily the default IDENTIKEY Authentication Server Base Policy - which does not inherit any attributes from
any other policies (i.e. parentless policies).
Policy attributes can be overridden - you can set authentication policy settings at the user level for the following
attributes:
n Local Authentication
n back-end authentication
n Offline Authentication
n Max Days Between Authentications
n Virtual Mobile Authenticator Delivery
IDENTIKEY Authentication Server 3.20 – Product Guide 184
13. Policies
n Virtual Mobile Authenticator MDC Profile
n Virtual Signature Delivery
n Virtual Signature MDC Profile
When configured at the user level, these settings will override those set by the parent policy.
13.3. Pre-Loaded Policies
Pre-loaded policies are created for IDENTIKEY Authentication Server during installation and provide useful policy
examples for typical environments.
The Base Policy provides globally applicable settings. In general, all other policies should inherit from it, either dir-
ectly or indirectly.
Non-default settings for Base Policy are as follows:
n Applicable DIGIPASS - Allow PIN change = Yes
n User Lock Threshold = 3
n Challenge Request Method = Keyword
n Virtual Mobile Authenticator - Delivery Method = SMS
n Primary Virtual Mobile Authenticator - Request Method = Password
n Backup Virtual Mobile Authenticator- Request Method = KeywordPassword
n Backup Virtual Mobile Authenticator - Request Keyword = otp
n Identification Time Window = 20
n Signature Time Window = 20
n Challenge Check Mode = 1
n Event Window = 20
n Sync-Window = 6
n Online Signature Level = 0
n Identification Threshold = 0
n Signature Threshold = 0
n Local Authentication = None
n Back-End Authentication = None
n Back-End Protocol = <empty>
n Dynamic User Registration = No
n Password Autolearn = No
n Stored Password Proxy = No
n Group-Check-Mode = No Check
n DIGIPASS Assignment - Assignment Mode = Neither
n Search Upwards in Org. Unit Hierarchy = No
n Application Type = No Restriction
n 1-Step Challenge/Response - Permitted = No
n 1-Step Challenge/Response - Add Check Digit = No
n Backup Virtual Mobile Authenticator - BVDP Mode = No
n Offline Authentication Enabled = No
n Offline Time Window = 21
n Offline Event Window = 300
n DCR - Enabled = No
IDENTIKEY Authentication Server 3.20 – Product Guide 185
13. Policies
n Password Randomization - Enabled = No
n Password Randomization - Back-End Password Length = 16
n Client-Group-Mode = No Check
n Second-OTP-Synch-Enabled = No
n Reply RADIUS Attributes = No
n RADIUS - Supported Protocols = Any
n RADIUS - Wireless Session Lifetime = 3600
n RADIUS - TLS Session Lifetime = 86400
n RADIUS - Maximum Fast Reconnect Count = 48
n Radius-Session-Ticket-Group-List = <empty>
n Static Password - Different From Last # Passwords = 4
n Static Password - Minimum Password Length = 7
n Static Password - Minimum # Lowercase Characters = 1
n Static Password - Minimum # Uppercase Characters = 1
n Static Password - Minimum # Numerical Digits = 1
n Static Password - Minimum # Special Characters = 0
n Static Password - Not Based on User ID = Yes
n Max Days Between Authentications = 90
n Multiple DIGIPASS App Validation Mode = Multiple DIGIPASS Applications Allowed
n Local Admin Users = Reject
n Virtual Signature - Delivery Method = SMS
n Virtual Signature - Virtual Signature Mode = No
n Virtual Signature - MDC Profile = <empty>
n DIGIPASS Assignment - Expiration Period = 0
n Secure Channel Support = Yes - Permitted
n Secure Channel - Activation Message Validity Period = 365
n Message Signing - Allow Custom Request Body = No
n Message Signing - Min App Version = 0
n 1-Step Challenge/Response - Require PIN = Yes
n 1-Step Challenge/Response - Template Number = 0
n 1-Step Challenge/Response - Font Index = 0
n Signature Transaction - Require PIN = Yes
n Signature Transaction - Template Number = 0
n Signature Transaction - Font Index = 0
n Signature Transaction - Show Response = Yes
n Signature Transaction - Show Warning = No
n Delayed Activation - Delay Period = 0
n Delayed Activation - Notify user when activation process starts = No
n Delayed Activation - Notify user when activation process completes = No
n Delayed Activation - Delivery Method = SMS
n Account Lockout - User Lock Threshold = 30
n Account Lockout - Lock Duration Multiplier = 150
n Account Lockout - Maximum Unlock Tries = 0
n User Info Synchronization = No
n Static Password - Maximum Age in Days = 42
n Static Password - Minimum Age in Days = 1
n Static Password - Days to Notify before Expiration = 8
n Push Notification - Request Method = KeywordPassword
IDENTIKEY Authentication Server 3.20 – Product Guide 186
13. Policies
n Push Notification - Request Keyword = push
n Push Notification - Mobile Application Name = <empty>
n Push Notification - Authentication Timeout (seconds) = 30
n Virtual DIGIPASS - Challenge Message = Enter One-Time Password
IDENTIKEY Authentication Server 3.20 – Product Guide 187
14. Reporting
14. Reporting
IDENTIKEY Authentication Server allows you to define and run a wide range of detailed reports. Reporting aspects
include desired fields, runtime query options, permissions, templates and scheduling. You can use pre-defined
standard reports, which can be edited, or you can define elements to create your own customized reports. Reports
are managed via the Administration Web Interface.
For detailed instructions on reporting tasks, refer to the Reporting chapter in the IDENTIKEY Authentication Server
Administrator Guide.
For a list of factors to consider when configuring reporting, refer to 14.2. Considerations for Reporting and
Auditing.
14.1. Reporting Features and Settings
Reports are created by collecting and manipulating data from a variety of sources. The principle concepts and fea-
tures behind reporting in IDENTIKEY Authentication Server are described in the following sections.
14.1.1. Report Type
There are four general types of IDENTIKEY Authentication Server reports:
n List Analysis. Lists all items that match the criteria specified in the report definition, e.g. a list of users with
no DIGIPASS assigned.
n Detailed Analysis. Shows detail of the events specified in the report definition, e.g. a detailed list of failed
authentications for a user.
n Distribution Analysis. Shows a count of events and objects, e.g. the number of failed authentications for a
domain.
n Trend Analysis. Shows a trend over a period of time for the objects specified in the report definition. For
Trend Analysis reports, there is an extra parameter: the period of time for which the data needs to be
extracted must be specified by hour, day, month, and year.
All reports, whether standard or custom, are based on these report types. Each report type retrieves information
from either the audit data, the data store, or both.
14.1.2. Grouping Level
The grouping level specifies how the data in the report will be grouped:
n Client. If a report has set grouping level to Client, each (physical) client connected will be represented indi-
vidually.
n Domain.
IDENTIKEY Authentication Server 3.20 – Product Guide 188
14. Reporting
n Organizational Unit. If a detailed or list report has set grouping level to Organizational Unit, the data for all
the users in that organizational unit will be added together and represented only once under the organ-
izational unit.
n User. If a detailed or list report has set at grouping level to User, each user will be represented individually.
n Digipass.
14.1.3. Data Source
Each report is generated from data existing on IDENTIKEY Authentication Server:
n Users. Generates the report based on the user information from the IDENTIKEY Authentication Server data
store.
n Users + Audit Data. Generates the report based on the user information mentioned above, and the audit
data from IDENTIKEY Authentication Server.
n Digipass. Generates the report based on the authenticator information from the IDENTIKEY Authentication
Server data store.
n Digipass + Audit Data. Generates the report based on the authenticator information mentioned above,
and the audit data from IDENTIKEY Authentication Server.
n Audit Data. Generates the report based on the audit data only. This means that the results are grouped by
the distinct grouping objects, e.g. client components, found in the audit data for the selected reporting
time period, whether they currently exist in the IDENTIKEY Authentication Server database or not.
n Users + Digipass. Generates the report based on the user and authenticator information from the
IDENTIKEY Authentication Server data store. This option can be used for list or detailed analysis reports
only.
14.1.4. Administrative Scope of Reports
The administrative scope of reports allows to define for which part of the organizational structure the report is to
be generated and run. Via this administrative scope it is possible to determine which users, DIGIPASS authen-
ticators, organizational units, and domains are to be included in the report processing and the relevant output.
14.1.4.1. ODBC vs. Active Directory Storage
The definition of the administrative scope depends on the selected storage type of the relevant IDENTIKEY
Authentication Server deployment.
n ODBC Storage
n All domains. Running the report is initiated by a Master Domain administrator; objects are pro-
cessed over all domains, including the Master Domain.
n Single domain. Running the report is initiated by a single domain administrator; objects which are
part of that same domain are processed.
n Multiple domains. Running the report is initiated by a multiple domain administrator; objects
which are part of those domains for which the administrator has the relevant permissions are pro-
cessed.
IDENTIKEY Authentication Server 3.20 – Product Guide 189
14. Reporting
n Org unit and all child org units. Running the report is initiated by an organizational unit
administrator; objects which are part of that organizational unit and all its child organizational
units are processed.
n Active Directory Storage
n All domains. Running the report includes all organizational units as well as the DIGIPASS pool and
DIGIPASS reserve containers.
n Domain. Running the report includes the domain where the administrator account has been
defined; this includes all organizational units as well as the DIGIPASS pool and DIGIPASS reserve
containers in this domain.
n Org unit and all child org units. Running the report for a selection of one or more organizational
units in the domain for which the administrator account has been defined. The DIGIPASS pool and
DIGIPASS reserve containers are in this case also treated as organizational units.
Note
The administrative scope is not applicable to reports on client applications.
14.1.5. Time Zone
When configuring report settings, you can specify a time zone. This selected time zone will be used for:
n The report's specified time period
n All logs in the report (if any)
14.1.6. Fields
You can filter report data at a field level, but only if:
n The report type is Detailed Analysis or List Analysis reports
n The data is selected from the Audit data source
If no specific fields are selected, then all fields are included in the report. For example, your report could display
the number of session times over one hour within the past week.
14.1.7. Query
You can further customize reporting data by setting one or more Queries.
For example, to generate a report for a specific audit message, e.g. Authentication, you can specify the fol-
lowing line in your query:
Audit Message = 'Authentication'
You will then only receive information on Authentication audit messages in your report.
IDENTIKEY Authentication Server 3.20 – Product Guide 190
14. Reporting
You can use multiple queries to gain even finer-grained control of data. For example, the Authentication Activity by
Client report includes the following query data:
Audit:Category equals Authentication,
Audit:Type equals success,
Audit:Code equals S-002001,
Audit:Code equals S-010001
The Query value field can also recognize free text for time values. For example:
Audit:Timestamp + is greater than + “6 months ago”
14.1.8. Permissions
Each report definition has an owner. The owner is usually the administrator that created the report, but ownership
can be transferred to another administrator in the same domain. Permissions associated with each report determ-
ine:
n Who can run the report. Use can be restricted to the report owner, or it can be granted to other admin-
istrators.
n Who can change the report definitions. The ability to change the report format and details can be restric-
ted to the report owner, or it can be granted to other administrators.
n Who can view the report.
Usage Permissions
There are three types of usage permissions:
n Private. Only the owner can view and run the report.
n Domain. The report can be run and viewed only by administrators that belong to the domain where the
report was defined.
n Public. All administrators in all domains can view and run the report.
Change Permissions
There are three types of change permissions:
n Private. Only the owner can change the report.
n Domain. The report can be changed only by administrators that belong to the domain where the report
was defined.
n Public. All administrators in all domains can change the report.
Permissions for Standard Reports
Standard reports have private permissions relating to changing the reports, and public permissions relating to
running and viewing the reports.
IDENTIKEY Authentication Server 3.20 – Product Guide 191
14. Reporting
14.1.9. Templates
Reports can be generated in XML, HTML or PDF format. When defining a report, you can either:
n use the default XML or PDF templates, or
n provide your own custom template definition.
Templates are defined when creating a report, and are then selected from a list when running the report. Each
report definition can have more than one formatting template.
Report data is always generated (initially) into XML. An SQL query retrieves the data that is required for the report.
XML and HTML Reports
IDENTIKEY Authentication Server supports XSLT transformation to produce desired reporting output. The result
of the SQL query and the report type are then combined into an XML report. The XML report and the report
format template are combined to produce the finished report in the required format (XML or HTML).
PDF
The XML data is run through a PDF generator to produce a basic PDF report. This is then combined with the
template data (including header, footer and logo data), to provide a finished PDF with bookmarked headline
sections. The PDF header, footer and logo data can be customized, or use the standard template.
Note
Only PDF reports can be run from the background. As such, running a report with XML or HTML outputs will lock
the Administration Web Interface until the reporting task is completed.
14.2. Considerations for Reporting and Auditing
When creating reports you should consider how your data is stored, made available for reports, and archived. The
reports you can run use the audit data and the data store.
An issue arises when you have more than one instances of IDENTIKEY Authentication Server in your system. Audit
messages can be stored on a database or in local text files. The database storage option can be local or cent-
ralized; text files are local.
When a report is run, the data has to be in a database. The report can only read one database at a time, so if (a)
there is more than one IDENTIKEY Authentication Server instances writing audit data to individual databases or (b)
the audit data is being written to one or more text files, the following options are available to enable reports to run
on all audit data:
IDENTIKEY Authentication Server 3.20 – Product Guide 192
14. Reporting
Online Centralized Database
If you have a centralized audit database, all instances of IDENTIKEY Authentication Server will write to this
database all the time. All reports can be run against this database all the time. If the centralized database is
used it must be configured to be fast enough and big enough to cope with the load of audit data.
Note
If you choose to install the embedded MariaDB database with IDENTIKEY Authentication Server, your default
audit method will be ODBC database. In addition, IDENTIKEY Authentication Server will automatically configure
DSN according to the settings used during installation.
Tip
You can also edit the settings for DSN, user name, and password in the ODBC Audit Settings tab in the Reporting
and Audit scenarios and the Auditing section of the IDENTIKEY Authentication Server Configuration Utility.
Offline Centralized Database
Write the audit data locally but periodically load the local data to a centralized audit database. Each
IDENTIKEY Authentication Server must be configured to read the audit data from the centralized database.
Reports will only contain data up to the last load to the centralized audit database.
Offline Centralized Database with Reporting Server
Write the audit data locally but periodically load the local data to a centralized audit database. Each
IDENTIKEY Authentication Server must be configured to read the audit data from the local audit data source. A
reporting server can be installed that is configured to read its data from the centralized audit database.
Reports that need to use up to the minute data can be run on the server that retrieves its data locally. An
example of this would be a user activity report for troubleshooting.
Reports that need to use global data can be run on the reporting server. Reports will only contain data up to
the last load to the centralized audit database.
No Centralized Audit Data
Configure each IDENTIKEY Authentication Server to retrieve audit report data locally.
An option to Upload Audit Data is available in the Maintenance Wizard . This will allow you to configure
IDENTIKEY Authentication Server to upload local audit data to a centralized audit database.
Archiving Strategy
If you are running reports that will require data spread out over a long period of time, the reports will take a
long time to run as the volume of data gets bigger. The best way of dealing with this growth is to archive the
data. It is best to develop a good archiving strategy when your system is being implemented. Consider the
kind of data you will want to report on, and the length of time you would like data to be available before
being archived. Remember, archived data cannot be reported upon.
IDENTIKEY Authentication Server 3.20 – Product Guide 193
14. Reporting
Indexing
When reports that use large amounts of data are produced, they can take a long time to process. To help
make these reports run faster you can add additional indexing to the searchable fields on the database.
If you intend to work with the User Dashboard and view recent user and DIGIPASS activity, it is recommended
that you set the level of indexing for the vdsAuditMsg table to 1, to prevent authentication and report per-
formance loss. For more information about the various levels of indexing, refer to the IDENTIKEY Authentic-
ation Server Administrator Reference.
Decreasing the Maximum Report Size
You can also decrease the size of generated reports via the Report-Size-Limit parameter. Doing so
helps prevent the reporting process from consuming too much memory.
The Report-Size-Limit parameter is configured directly in the IDENTIKEY Authentication Server con-
figuration file; namely, identikeyconfig.xml. This file is located in:
/etc/vasco/ias/ (Linux)
<install_dir>\bin\ (Windows)
where <install_ dir> is the installation directory of IDENTIKEY Authentication Server (typically
%PROGRAMFILES%\VASCO\IDENTIKEY Authentication Server)
This parameter is listed under Report-Location in the Reporting Scenario configuration, i.e. nested
under ScenarioModule4. Report-Size-Limit dictates a data point limit; in this case, the data
point limit is the maximum number of distinct data fields (i.e. each user ID, domain, or organizational unit
entry) shown in a report. The data point limit effectively limits the size of the report.
The default Report-Size-Limit value is 100000. While this is adequate for most installations, you
can decrease this value if running a reporting task slows down IDENTIKEY Authentication Server significantly.
Keep in mind, though, that altering the Report-Size-Limit value requires that you restart IDENTIKEY
Authentication Server.
Note
IDENTIKEY Authentication Server uses a third-party library – Haru – to generate PDF reports; Haru has an
internal PDF size limit. Increasing the Report-Size-Limit also increases the chances of reaching
Haru's PDF size limit. When this occurs, the reporting task will fail.
As such, if you need to increase the Report-Size-Limit value, use the XML or HTML report tem-
plates instead.
IDENTIKEY Authentication Server 3.20 – Product Guide 194
14. Reporting
14.2.1. Generating Reports in Environments with Multiple IDENTIKEY Authentication Server Instances
In environments with multiple IDENTIKEY Authentication Server instances, generating reports and other admin-
istrative tasks can be handled in different ways, depending on the database and replication setup of your system.
For more information about how administrative tasks are performed in multi-server environments, refer to 9.11.
Administration with Multiple IDENTIKEY Authentication Server Instances.
14.2.1.1. Multiple Reports and Load Balancing
To optimize CPU and memory usage, multiple report tasks are processed in serial order, with each IDENTIKEY
Authentication Server instance allowed to run one report task at a time. By default, multiple report tasks are dis-
tributed across all server instances and are thus automatically load balanced.
If you want to run reports solely on a dedicated reporting server, you need to disable the Reporting Scenario in the
IDENTIKEY Authentication Server Configuration Utility for all other IDENTIKEY Authentication Server instances. In this
case, the reporting server will be the only instance for report handling, and it will process and run one report task
at a time.
Note
In environments with a dedicated reporting server, if you connect to an IDENTIKEY Authentication Server instance
that has the Reporting Scenario disabled, the REPORTS menu will not be displayed in the Administration Web
Interface.
You can create and run report tasks only when connected to the reporting server instance.
IDENTIKEY Authentication Server 3.20 – Product Guide 195
15. Wireless RADIUS
15. Wireless RADIUS
IDENTIKEY Authentication Server supports authentication over a wireless connection via the RADIUS protocol.
Image 54: Wireless RADIUS Components
An authentication service using wireless RADIUS has the following components:
n Supplicant: The machine from which a wireless access request originates.
n Wireless Access Point: A wireless network signal transmitter and receiver. The Wireless Access Point must
be configured to use one of the following wireless protocols:
n WPA Enterprise
n WPA2 Enterprise
n Authenticator: The machine to which the Wireless Access Point passes authentication requests.
Warning
OneSpan does not recommend the use of the TKIP encryption algorithm on wireless networks due to inherent
security issues. Configure your WAP(s) to use the AES algorithm.
15.1. Fast Reconnect
Wireless sessions may be renewed at regular intervals by using Fast Reconnect.
When a one-time password authentication is performed, a session ID is assigned to the wireless connection. Fast
Reconnect uses this session ID to automatically re-authenticate the wireless connection rather than requiring user
ID and one-time password input from the user.
In order for Fast Reconnect to occur, a record must exist in the data store for the wireless access point making the
Fast Reconnect request.
IDENTIKEY Authentication Server 3.20 – Product Guide 196
15. Wireless RADIUS
Image 55: Fast reconnect Overview
15.1.1. Fast Reconnect Authentication Process
During a Fast Reconnect, the Authentication Process proceeds as follows:
1. IDENTIKEY Authentication Server retrieves the policy to use from the component record.
2. IDENTIKEY Authentication Serverperforms the following checks:
n Windows username/domain resolution (if used)
n Windows Group Check
n Whether the user has a DIGIPASS user account
n Whether the user's DIGIPASS user account is disabled or locked
3. Optional: If back-end authentication and Stored Password Proxy are enabled, IDENTIKEY Authentication
Server checks the stored static password with another system (e.g. Windows or RADIUS).
4. Authentication result is audited and returned.
15.1.2. Roaming Connections
Users are considered to be 'roaming' where:
n Multiple wireless access points are available, and
n The user may connect to more than one wireless access point, and
n The user will be moving from the range of one wireless access point to another.
A change from one wireless access point to the next can be made without inconvenience to the user when Fast
Reconnect can be used between the access points.
Note
Roaming connections are not supported over multiple instances of IDENTIKEY Authentication Server.
Fast reconnect will only work for roaming wireless connections where:
IDENTIKEY Authentication Server 3.20 – Product Guide 197
15. Wireless RADIUS
n All wireless access points are sending authentication requests to the same IDENTIKEY Authentication
Server instance
n All component records for the wireless access points are using the same policy
n All wireless access points are configured to use the same SSID
Image 56: Roaming Wireless Fast Reconnection
15.2. Multiple Roaming Zones
Multiple roaming zones – where roaming wireless connections are not permitted between zones - may be estab-
lished by assigning different SSIDs to wireless access points in different zones, and using different policies for com-
ponents in each zone. The following diagram illustrates how Fast Reconnect works with an environment with
multiple roaming zones.
IDENTIKEY Authentication Server 3.20 – Product Guide 198
15. Wireless RADIUS
Image 57: Roaming Wireless Fast Reconnection – Roaming Zones
IDENTIKEY Authentication Server 3.20 – Product Guide 199
16. IDENTIKEY Authentication Server and Active Directory
16. IDENTIKEY Authentication Server and Active Directory
IDENTIKEY Authentication Server operates within the pre-existing Active Directory domain and organizational
unit structure. Each DIGIPASS user and DIGIPASS must belong to a domain in Active Directory. User IDs must
be unique within a domain, but may be repeated between domains.
While DIGIPASS user account and DIGIPASS records can belong to any domain, a single domain is identified
during installation as the DIGIPASS Configuration Domain. This domain is used to store the following records:
n Component
n Policy
n Back-end server
When no domain is specified, the DIGIPASS configuration domain is also used as a default domain for user
lookup.
Whenever IDENTIKEY Authentication Server uses an Active Directory data store, the following information is stored
in Active Directory:
n DIGIPASS user account
n DIGIPASS and DIGIPASS Application records
n DIGIPASS configuration records (Policies, Components, Back-end servers, Reports and Report formats)
n IDENTIKEY Authentication Server configuration information
Warning
You cannot import DIGIPASS licenses prepared for the Multi-Device Licensing and Activation model, if IDENTIKEY
Authentication Server has been configured to use Active Directory (AD) as data storage.
Multi-Device Licensing is not supported in those cases; importing a respective .dpx file will fail with an appro-
priate error message.
16.1. Schema Extensions
An Active Directory data store uses the following schema extensions:
User attributes – vasco-UserExt class
Extra OneSpan attributes are added to an Active Directory user record via an auxiliary class vasco-
UserExt on the User class.
DIGIPASS and DIGIPASS Application records
The vasco-DPToken class is used to store DIGIPASS attributes. It is also a container, in which vasco-
DPApplication records for that DIGIPASS are stored.
Upon assignment to a user, the DIGIPASS record is stored in the same location as the user.
IDENTIKEY Authentication Server 3.20 – Product Guide 200
16. IDENTIKEY Authentication Server and Active Directory
Policies, Components and Back-End Servers
Policy, Component, Back-end server, Report and Report format records are stored in vasco-Policy,
vasco- Component , vasco- BackEndServer , vasco- Report , and vasco-
ReportFormat objects respectively. They are located in a single Digipass-Configuration con-
tainer in a single domain.
16.2. DIGIPASS Records
When a DIGIPASS is assigned to a user, it is moved to the same location as the DIGIPASS user account it is assigned
to. This makes it easier to set up the permissions necessary for delegated administration.
Note
A DIGIPASS record will not automatically be moved when the user account to which it is assigned is moved to
another location. When moving user accounts within Active Directory, ensure that the records of any assigned
DIGIPASS are manually moved to the same location.
Unassigned DIGIPASS Records may be stored in various places in the data store:
DIGIPASS Pool
A container called DIGIPASS-Pool is created during installation. This is intended as a general store for unas-
signed DIGIPASS.
Organizational Units
If an organizational unit structure is used in the data store, DIGIPASS can be loaded or moved either into the
exact organizational units where the user accounts to which they will be assigned are located, or into a few
key organizational units in the hierarchy where they may be assigned to users in lower level organizational
units.
Users Container
When Active Directory is used as the data store, DIGIPASS can be loaded into the users container so they are
available for users in that container. However, it is not recommended to use the users container for either
user accounts or DIGIPASS.
When looking for an available DIGIPASS to assign to a user, the IDENTIKEY Authentication Server will first look in
the same organizational unit as the specific user account. The search upwards in organizational unit hierarchy
option, when enabled, allows the IDENTIKEY Authentication Server to search in parent organizational units and the
DIGIPASS-Pool container. This option may be set at the policy level for system searches (i.e. Auto-Assignment and
Self-Assignment) or at the time of the search for manual assignment.
Note
IDENTIKEY Authentication Server will always find or assign the closest available DIGIPASS record to the selected
IDENTIKEY Authentication Server 3.20 – Product Guide 201
16. IDENTIKEY Authentication Server and Active Directory
user record(s).
16.2.1. Delegated Administration in Active Directory
If the assignment is manual (performed by an administrator), it will only find and successfully assign DIGIPASS from
locations where the administrator has the correct permissions. The administrator must have read permission for
DIGIPASS objects in the location to find a DIGIPASS record, and if it needs to be moved to the user's location, they
must have delete permission for DIGIPASS objects to successfully assign the DIGIPASS. If the administrator has suf-
ficient permissions to view a DIGIPASS record but not to assign it, the assignment will fail.
Table 14: Summary of DIGIPASS record location options
Record Location Pros Cons
DIGIPASS Pool DIGIPASS are available to be assigned to all users, regard- An extra permission must be assigned to all admin-
less of the organizational unit structure. istrators who should be able to assign DIGIPASS (if
they are not domain admins).
Only administrators with access to the DIGIPASS Pool may
view or modify records for unassigned DIGIPASS. It is not possible to strictly subdivide the unas-
signed DIGIPASS among the organizational units
This also means that only those administrators may manu- according to quotas.
ally assign DIGIPASS.
Organizational Unit DIGIPASS may be portioned out to various organizational If an organizational unit runs out of DIGIPASS to
units. assign its users, more DIGIPASS records must be
manually moved to the right location.
This is particularly useful where a company is contracted
to provide authentication services to multiple companies,
or where various departments have different DIGIPASS
quota.
Users Container DIGIPASS can be assigned to any user in the users con- DIGIPASS in the users container are only available
tainer. to user accounts stored there.
16.2.2. Typical DIGIPASS Location Models for Active Directory
16.2.2.1. DIGIPASS Pool
A centralized point of access and importation can be implemented by using the DIGIPASS pool to hold unassigned
DIGIPASS records. This option requires less calculation and high-level administration, as DIGIPASS records are all
imported into one area and there is no need to manually move records or calculate the exact number of DIGIPASS
required for each organizational unit or group of Units. However, permissions will need to be set up to permit del-
egated administrators access to move the DIGIPASS out of the container upon assignment.
The DIGIPASS Pool is treated as the Domain Root by the IDENTIKEY Authentication Server, as DIGIPASS records may
not be saved in the Domain Root.
IDENTIKEY Authentication Server 3.20 – Product Guide 202
16. IDENTIKEY Authentication Server and Active Directory
Image 58: DIGIPASS Record Locations - DIGIPASS Pool
In this diagram, the IDENTIKEY Authentication Server is shown searching upwards through the organizational unit
structure for available DIGIPASS to assign to a DIGIPASS user in the organizational unit B1. Because no available
DIGIPASS are found in B1, it searches in B, then in the DIGIPASS pool.
Administrator 1 needs delegated administrator permissions for the organizational unit B and its child organ-
izational units. They must also have read and delete permissions for DIGIPASS objects in the DIGIPASS pool con-
tainer.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
16.2.2.2. Parent Organizational Units
Unassigned DIGIPASS can be kept in key organizational units, and made available to their lower level organ-
izational units. This requires a delegated administrator to have permissions not only for the organizational unit in
which the user accounts are stored, but also read, write and delete permissions for DIGIPASS objects in the organ-
izational unit in which the DIGIPASS are stored.
IDENTIKEY Authentication Server 3.20 – Product Guide 203
16. IDENTIKEY Authentication Server and Active Directory
Image 59: DIGIPASS Record Locations - Parent Organizational Unit
In the diagram above, the IDENTIKEY Authentication Server can search in the parent organizational unit for avail-
able DIGIPASS.
The delegated administration permissions can be set up in two basic ways:
Administrator 1 has full admin permissions for organizational unit B and its child organizational units. She does not
require any other permissions to assign DIGIPASS from organizational unit B to a user in organizational unit B1.
Administrator 2 has full admin permissions for organizational unit A2 only. He has read and delete permissions for
DIGIPASS objects in organizational unit A in order to assign DIGIPASS from organizational unit A to a user in organ-
izational unit A2.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
16.2.2.3. Individual Organizational Units
DIGIPASS can be loaded or moved into each organizational unit where and when they are required. It is then easy
to set up permissions for delegated administrators to assign them only within their scope of control. If all DIGIPASS
IDENTIKEY Authentication Server 3.20 – Product Guide 204
16. IDENTIKEY Authentication Server and Active Directory
in the organizational unit are assigned, more DIGIPASS will need to be moved in manually by a domain admin
before they can be assigned by a delegated administrator.
Image 60: DIGIPASS Record Locations - Individual Organizational Units
In the diagram above, unassigned DIGIPASS are stored in the exact organizational units in which they will be
assigned.
Each delegated administrator only requires permissions within their specific organizational unit(s).
Note
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for this model.
16.2.2.4. Combination of models
DIGIPASS may be stored in the DIGIPASS Pool as well as some or all organizational units. If no unassigned DIGIPASS
records are found in the organizational unit, and the Search Upwards in Organization Unit hierarchy option is
enabled, IDENTIKEY Authentication Server will search upwards to the domain root and search in the DIGIPASS Pool
for an available, unassigned DIGIPASS record.
16.3. Permissions Needed by IDENTIKEY Authentication Server for Active Directory
The installation process will ensure that the IDENTIKEY Authentication Server has sufficient permissions. This is
achieved by assigning permissions in the domain to the in-built RAS and IAS Servers group. It is neces-
sary to make sure that the IDENTIKEY Authentication Server is added to that group.
Note
For ANY group that uses back-end authentication via LDAP and Active Directory, the permission List contents
IDENTIKEY Authentication Server 3.20 – Product Guide 205
16. IDENTIKEY Authentication Server and Active Directory
must be granted in the Active Directory Users and Computers Extension.
16.4. Administrative Permissions Used by IDENTIKEY Authentication Server
Administrative permissions for IDENTIKEY Authentication Server administrators are controlled using Active Directory
security properties. Refer to the Permissions Needed by Administrators topic in the IDENTIKEY Authentication
Server Administrator Reference for more information.
Domain administrators may view and edit all DIGIPASS and DIGIPASS user information in their domain, plus
DIGIPASS configuration information if the DIGIPASS configuration container is located in their domain. No per-
missions setup is required for them.
Delegated administrators may view and edit all DIGIPASS and DIGIPASS user information within their administrative
scope of control. It is necessary to grant them full control, create and delete permissions over the DIGIPASS and
DIGIPASS Application objects within their scope.
Reduced Rights Administrators may perform a subset of the administration tasks. Property sets are defined with
the directory which can be used to enable or limit them in various DIGIPASS administration tasks (i.e. Access to the
DIGIPASS BLOB).
16.5. Active Directory Command-Line Utility (dpadadmin)
The Active Directory Command-Line Utility (dpadadmin) has to perform several tasks that are needed at various
times during installation and upgrade if Active Directory is selected, or afterward for maintenance. Some of the
commands are run automatically by the installation program, while others are run manually. The commands that
are run automatically can be run manually also, for example to troubleshoot why the installation is not succeeding.
Note
On some versions of Windows, the use of this utility will require an administrator login to the IDENTIKEY Authentic-
ation Server host. Because of this, you may be prompted to either:
n Confirm that the utility should be run as an administrator.
n Enter valid administrator credentials for the IDENTIKEY Authentication Server host.
The purpose of either prompt is to elevate your privileges to those required by the utility you are attempting to
run. If you cannot elevate your privileges, the utility will run in an underprivileged state, which will likely result in
unexpected behavior.
Table 15: dpadadmin Commands
Command Description
addschema Extend the Active Directory schema.
checkschema Check that the schema extensions are all present.
IDENTIKEY Authentication Server 3.20 – Product Guide 206
16. IDENTIKEY Authentication Server and Active Directory
Table 15: dpadadmin Commands (continued)
Command Description
generateldif Generate an LDAP Data Interchange Format (LDIF) file containing the schema extensions.
setupaccess Assign permissions to a Windows group.
This includes:
n Full read access to everything in the domain
n Full control over vasco-DPToken objects
n Full control over vasco-DPApplication objects
n Ability to create and delete vasco-DPToken objects
n Full write access to extension attributes on user objects
This command can optionally be used to also add a machine to the group.
setupdomain Set up the DIGIPASS configuration container in the specified domain.
To run dpadadmin , you need to copy dpadadmin.exe to the computer from which the AD database can be
accessed.
You can retrieve dpadadmin.exe from the installation folder (by default %PROGRAMFILES%\VASCO\IDENTIKEY
Authentication Server) or from the following folder on the product installation CD:
\Software\Windows\Utilities\dpadadmin
16.5.1. Active Directory Replication
For more information about Active Directory replication, refer to the IDENTIKEY Authentication Server Administrator
Guide, Section "Active Directory Replication Issues".
IDENTIKEY Authentication Server 3.20 – Product Guide 207
17. ODBC Data Store
17. ODBC Data Store
IDENTIKEY Authentication Server includes an embedded MariaDB database, which you can use as a data store.
You can also use another ODBC-compliant database instead.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), be aware that when selecting
the embedded MariaDB during installation, you will be prompted to choose whether or not to use encryption. By
selecting Yes, IDENTIKEY Authentication Server will use data-at-rest encryption for the database, and use ODBC
connection encryption by default.
When selecting the Advanced installation option and not opting for a MariaDB database, you are responsible for
protecting the database and the connections to it.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
Whenever IDENTIKEY Authentication Server uses an ODBC-compliant database as a data store, the following
information is stored in the data store:
n DIGIPASS user accounts
n DIGIPASS and DIGIPASS Application records
n DIGIPASS configuration records (Policies, Components, Back-end servers, Reports and Report formats)
n IDENTIKEY Authentication Server configuration information
Note
When copying, migrating, or backing up encrypted database files, ensure that the encryption key (and/or the
optional password key) is also backed up. Otherwise, you will not be able to read the data, as it will be encryp-
ted.
17.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 accord-
ing to department, job function, or other criteria. They also allow DIGIPASS to be allocated for Auto-Assignment to
single or multiple groups of users. Both domains and organizational units can be used to limit administrators to a
group of users and/or DIGIPASS.
IDENTIKEY Authentication Server 3.20 – Product Guide 208
17. ODBC Data Store
Image 61: Domains and Organizational Units
For more information about domains and organizational units, refer to 2.9. IDENTIKEY Authentication Server Data
Model
17.2. DIGIPASS Records Location
When a DIGIPASS is assigned to a user, it is moved to the same organizational unit as the DIGIPASS user account to
which it is assigned.
Note
When a user account is moved to an organizational unit, all DIGIPASS records assigned to it will also be moved.
A DIGIPASS record assigned to a user cannot be moved, the user account must be moved. Unassigned DIGIPASS
records may be allocated to various places in the organizational unit structure:
Master Domain
During installation, a default domain is created. DIGIPASS are imported to the Master Domain, and may then
be moved to other domains and organizational units.
IDENTIKEY Authentication Server 3.20 – Product Guide 209
17. ODBC Data Store
Organizational Units
If an organizational unit structure is used in the database, DIGIPASS can be moved either into the exact organ-
izational units where the user accounts to which they will be assigned are located, or into a few key organ-
izational units in the hierarchy where they may be assigned to users in lower level organizational units.
When looking for an available DIGIPASS record for a device to assign to a user, the IDENTIKEY Authentication Server
will first look in the same organizational unit as the specific user account, if the user account belongs to an organ-
izational unit. The Search Upwards in Organizational Unit hierarchy option, when enabled, allows the IDENTIKEY
Authentication Server to search in parent organizational units and the DIGIPASS pool container. This option may be
set at the policy level for system searches (i.e. Auto-Assignment and Self-Assignment (see Section 11.2.2. Auto-
Assignment and Section 11.2.1. Self-Assignment) or at the time of the search for manual assignment.
Note
The IDENTIKEY Authentication Server will always find or assign the closest available DIGIPASS record to the selec-
ted user record(s).
If the user account being assigned a DIGIPASS record does not belong to an organizational unit, the IDENTIKEY
Authentication Server will look for an available DIGIPASS record which does not belong to an organizational unit,
i.e. for an available record stored directly in the domain.
17.2.1. Typical DIGIPASS Location Models for ODBC
Domain Root
DIGIPASS records may be stored in the domain root while unassigned.
This option allows a centralized point of access for assignment of DIGIPASS records. It also requires less calculation
and high-level administration - DIGIPASS records are all stored in one area and there is no need to manually move
records or calculate the exact number of DIGIPASS required for each organizational unit or group of units. Admin-
istrators must belong to the domain only (not an organizational unit) to assign DIGIPASS from the domain root.
IDENTIKEY Authentication Server 3.20 – Product Guide 210
17. ODBC Data Store
Image 62: DIGIPASS Record Locations – Domain Root
In the diagram above, the IDENTIKEY Authentication Server searches upwards through the organizational unit struc-
ture for available DIGIPASS record to assign to a DIGIPASS user in the organizational unit B1. Because no available
DIGIPASS records are found in B1, it searches in B, then in the domain root.
The administrator account manually assigning the DIGIPASS records must be located in the domain root (no organ-
izational unit) in order for this model to work successfully.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
This option is simplified if an organizational unit structure is not used in the database. User accounts and DIGIPASS
records may all be stored in the Master Domain. The Search Upwards in Organizational Unit hierarchy option does
not need to be enabled in this case.
17.2.1.1. Parent Organizational Units
Parent Organizational Units
Unassigned DIGIPASS records can be kept in key organizational units, and made available to their lower level
organizational units.
IDENTIKEY Authentication Server 3.20 – Product Guide 211
17. ODBC Data Store
Image 63: DIGIPASS Record Location – Parent Organizational Unit
In the diagram above, the IDENTIKEY Authentication Server can search in the parent organizational unit for avail-
able DIGIPASS records.
The administrator account manually assigning the DIGIPASS records must belong to the parent organizational unit.
Note
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to function correctly.
17.2.1.2. Individual Organizational Units
DIGIPASS records can be loaded or moved into each organizational unit where and when they are required. If all
DIGIPASS in the organizational unit are assigned, more DIGIPASS records will need to be moved in manually by a
domain administrator before they can be assigned.
IDENTIKEY Authentication Server 3.20 – Product Guide 212
17. ODBC Data Store
Image 64: DIGIPASS Record Locations – Individual Organizational Units
In the diagram above, unassigned DIGIPASS records are stored in the exact organizational units in which they will
be assigned.
Administrator accounts belonging to the organizational units A1 and A2 have administration privileges in their own
organizational unit only.
Note
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for this model.
17.2.1.3. Combination of models
DIGIPASS records may be stored in the Master Domain as well as some or all organizational units. If no unassigned
DIGIPASS records are found in the organizational unit, and the Search Upwards in Organization Unit hierarchy
option is enabled, then IDENTIKEY Authentication Server will search upwards to the domain root and search in the
DIGIPASS Pool for an available, unassigned DIGIPASS record.
17.3. Permissions Needed by IDENTIKEY Authentication Server for ODBC
IDENTIKEY Authentication Server will require any of the following:
n A database administrator account for the database
n Ownership of the OneSpan tables
n Permissions to insert, remove, read and modify rows in OneSpan tables
This is set up automatically if you choose to use the embedded MariaDB database. For more information about per-
missions required for administration tasks, refer to the IDENTIKEY Authentication Server Administrator Reference.
IDENTIKEY Authentication Server 3.20 – Product Guide 213
17. ODBC Data Store
17.4. ODBC Database Command-Line Utility (dpdbadmin)
The ODBC Database Command-Line Utility (dpdbadmin) performs several tasks needed at various times during
installation and upgrade, or afterward for maintenance. Some of the commands are run automatically by the
installation program, while others are run manually. The commands that are run automatically can also be run
manually, for example to troubleshoot why the installation is not succeeding. Table 16: dpdbadmin Commands
lists the available commands.
Note
dpdbadmin only retrieves tables that are owned by the calling user. For this reason, you need to use either
the table owner to call dpdbadmin, or use consistently the same user for database schema creation, update
and/or validation.
Table 16: dpdbadmin Commands
Command Description
addindex Enable indexing on searchable fields to enhance reporting performance.
addschema Modify the database structure to create the tables required by IDENTIKEY Authentication Server.
checkschema Check that the required database modifications and/or table name mapping have been completed.
dropindex Drop indexing for reporting performance.
dropschema Remove all database schema modifications from the database.
To run the dpdbadmin utility, you need to copy dpdbadmin.exe to the computer from which the ODBC database
can be accessed.
You can retrieve dpdbadmin.exe from the installation folder (by default %PROGRAMFILES%\VASCO\IDENTIKEY
Authentication Server) or from the product installation CD.
17.5. Additional ODBC Databases
A synchronized backup database may be set up for the IDENTIKEY Authentication Server. This helps to ensure con-
tinuous service if the main database fails. The synchronization can be a shadow database, a mirror or a replicated
copy.
The required synchronization must be set up according to the instructions provided by the database vendor. It is
strongly recommended to minimize the synchronization delay.
Once the database and any synchronization is set up, create a Data Source Name for the new database and add it
to the Configuration Utility.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), be aware that the destination
IDENTIKEY Authentication Server 3.20 – Product Guide 214
17. ODBC Data Store
database and connections to it must be encrypted. The IDENTIKEY Authentication Server embedded database
can be installed with data-at-rest encryption for the database, and ODBC connection encryption.
For more information on GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regulation
Compliance Guide.
Image 65: Additional ODBC databases
For more information, refer to the IDENTIKEY Authentication Server Administrator Guide, Section "Database Con-
nection Handling".
17.6. Multiple Instances of IDENTIKEY Authentication Server Using ODBC
If more than one IDENTIKEY Authentication Server instance is installed on the system, some additional setup may
be required.
If more than one IDENTIKEY Authentication Server instance is using the same ODBC database, no additional setup
steps are required. A backup database should be considered.
IDENTIKEY Authentication Server 3.20 – Product Guide 215
17. ODBC Data Store
Image 66: Multiple IDENTIKEY Authentication Server Using Single Database
17.7. Replication
When multiple IDENTIKEY Authentication Server are in use each with their own database, they can be configured to
replicate data changes between them, to keep all databases synchronized.
Warning
If you are running multiple IDENTIKEY Authentication Server instances using ODBC in a high-load scenario, we
strongly recommend to disable IDENTIKEY Authentication Server replication and set up replication on the ODBC
database server level instead.
Slow responses from the IDENTIKEY Authentication Server instances under load will disrupt the replication pro-
cess!
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), be aware that when using rep-
lication, the data to be replicated is temporarily stored in a local SQLite database, and then transferred via mes-
sages over the SEAL protocol to its destination. The data temporarily stored on the disk is unencrypted. To be
GDPR-compliant, OneSpan recommends to encrypt either the folder containing the replication database or the
hard disk, and setting up SSL-encryption for replication connections between the IDENTIKEY Authentication
IDENTIKEY Authentication Server 3.20 – Product Guide 216
17. ODBC Data Store
Server instances.
For more information on GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regulation
Compliance Guide.
17.7.1. Common Scenarios
Primary and Backup IDENTIKEY Authentication Server
The most common, and most basic, replication setup is used when a company has two IDENTIKEY Authentic-
ation Server instances – one primary, to which all authentication requests are customarily sent, and a backup
IDENTIKEY Authentication Server instance for use when the primary server is busy or unavailable. Replication
is usually set to occur very frequently.
Image 67: Replication between a Primary and Backup IDENTIKEY Authentication Server instance
Primary, Backup and Disaster Recovery IDENTIKEY Authentication Server
This scenario is often used when a company requires an offsite disaster recovery IDENTIKEY Authentication
Server and database.
IDENTIKEY Authentication Server 3.20 – Product Guide 217
17. ODBC Data Store
Image 68: Replication between Primary, Backup, and Disaster Recovery in IDENTIKEY Authentication Server
17.7.2. Other Scenarios
Other replication scenarios may also be used. For example, a company may have three IDENTIKEY Authentication
Server instances, all replicating to each other. This may keep data up to date better than a simpler replication
chain.
IDENTIKEY Authentication Server 3.20 – Product Guide 218
17. ODBC Data Store
Image 69: Replication between three IDENTIKEY Authentication Server instances
Or, a company might require two Primary IDENTIKEY Authentication Server instances, each with a backup
IDENTIKEY Authentication Server instance, and add in an extra replication link to speed up data communications:
IDENTIKEY Authentication Server 3.20 – Product Guide 219
17. ODBC Data Store
Image 70: Complex IDENTIKEY Authentication Server Replication Scenario
17.7.3. Using SSL with Replication
Security for replication can be further enhanced by enabling SSL. SSL can be enabled when defining the Rep-
lication destination server on the Configuration Utility. Use the destination server configuration page to provide the
SSL certficate, SSL password, and CA Certificate store.
For more information about enabling and configuring SSL for replication connections, refer to the IDENTIKEY
Authentication Server Administrator Guide, Section "Enabling SSL on Replication Connections".
17.8. Cache Persistence
Certain multi-step workflows in IDENTIKEY Authentication Server require caching, because state information that is
shared between individual steps must be available within IDENTIKEY Authentication Server.
These workflows include:
n Push Notification authentication
n Challenge/Response authentication (with or without Secure Channel)
n Provisioning (Standard and Multi-Device Licensing)
IDENTIKEY Authentication Server 3.20 – Product Guide 220
17. ODBC Data Store
n Secure Channel Signature
n Administrative Session
When multiple IDENTIKEY Authentication Server instances are working together, the above mentioned multi-step
commands use a cache written to the database which is available to all IDENTIKEY Authentication Server instances
that share the same database. This allows multi-step commands to be sent to any IDENTIKEY Authentication
Server instance that is part of the setup (i.e. share the same database).
This persistent cache mechanism removes in-memory cache limits. Moreover, the IDENTIKEY Authentication
Server service/daemon can be restarted without losing sessions.
Note
The Administration Web Interface now supports cache-specific settings. These cache settings can be found in
SERVERS > Global Configuration.
The settings can no longer be edited in the IDENTIKEY Authentication Server configuration file
(identikeyconfig.xml).
Note
Cache persistence is an important element used for the high-availability and maximum-availability deployment
models.
In the advanced deployment model caches are persistent for each IDENTIKEY Authentication Server instance.
However, cache data is not replicated between the instances using the IDENTIKEY Authentication Server rep-
lication mechanism.
For more information about the different deployment models, refer to the IDENTIKEY Authentication Server Per-
formance and Deployment Guide.
Note
Cache persistence is automatically disabled in IDENTIKEY Authentication Server deployments using Active Dir-
ectory as data store!
IDENTIKEY Authentication Server 3.20 – Product Guide 221
18. Licensing
18. Licensing
OneSpan products are licensed per client component record in the data store. The licensing relies upon a license
key which is checked when the IDENTIKEY Authentication Server starts. This license key is tied to the location (IP
address) where the IDENTIKEY Authentication Server is installed, and stored in the client component record for
IDENTIKEY Authentication Server.
IDENTIKEY Authentication Server will not authenticate a user without a correct license key, except to permit admin-
istration. A license key is required for all of the following:
n SOAP
n RADIUS
n Authentication Scenario
n Signature Validation Scenario
Licensing for Multiple Instances of IDENTIKEY Authentication Server
You can run multiple instances of IDENTIKEY Authentication Server on the same Linux host. Each instance of
IDENTIKEY Authentication Server will require its own valid license tied to the IP address of its corresponding
instance.
Re-licensing
You will need to obtain and load new license keys for your IDENTIKEY Authentication Server components in
the following situations:
n You need to change from an evaluation license to a permanent license.
n You need to enable new functionality.
n The IDENTIKEY Authentication Server IP address is going to change or has changed.
n You are upgrading to a higher major version of IDENTIKEY Authentication Server.
Note
Whenever you change or update the server license key, you need to reconfigure IDENTIKEY Authentication Server
replication!
18.1. Component Licenses
Some client components—such as the DIGIPASS Authentication Modules or DIGIPASS Authentication for Windows
Logon—require a license key to be loaded into their client component record. IDENTIKEY Authentication Server, to
which they connect, will otherwise reject all authentication requests from them.
SOAP and RADIUS Clients
SOAP and RADIUS functionality must be enabled in the IDENTIKEY Authentication Server license for these cli-
ents to be operative.
IDENTIKEY Authentication Server 3.20 – Product Guide 222
18. Licensing
DIGIPASS Authentication for Windows Logon
There are two pre-defined client components for DIGIPASS Authentication for Windows Logon. Whether a cli-
ent component license is required, depends on the client component used.
n DIGIPASS Authentication for Windows Logon is a pre-defined SOAP-based client component used for
DIGIPASS Authentication for Windows Logon 2.x. Client component records of this type require a valid cli-
ent component license.
A client component record of this type with location default is automatically created during installation. If
the client component used to serve an authentication request by a DIGIPASS Authentication for Windows
Logon client does not have a client component license, IDENTIKEY Authentication Server falls back on the
client component record with the default location. If the default client component record has no valid
license loaded either, the authentication request is rejected.
n Identikey Windows Logon Client is a pre- defined SEAL- based client component used for DIGIPASS
Authentication for Windows Logon 1.x. Client component records of this type do not require a client com-
ponent license. However, the SEAL and Windows Logon options must be enabled in the IDENTIKEY
Authentication Server license.
OneSpan User Websites
IDENTIKEY User Websites is a pre-defined SOAP-based client component used for OneSpan User Websites cli-
ents. Unlike other SOAP clients it does require a valid license key in the client component record. However, it
does not require SOAP authentication to be enabled in the IDENTIKEY Authentication Server license.
DIGIPASS Gateway
DIGIPASS Gateway is a pre-defined SOAP-based client component used for DIGIPASS Gateway clients in the
context of Push Notification. Unlike other SOAP clients it does require a valid license key in the client com-
ponent record. However, it does not require SOAP authentication to be enabled in the IDENTIKEY Authentic-
ation Server license.
18.2. Evaluation License
An evaluation license means that you can use its full functionality until the evaluation period runs out. At the end of
this period, you will need to either uninstall the product or buy a permanent license. Contact your distributor or the
appropriate OneSpan reseller representative to acquire the licenses you will need. For your convenience, the eval-
uation serial number is embedded in the installation program. You will still need to obtain and load a license key.
Client module licenses can also be evaluation (time-limited) licenses.
Note
Licenses for previous IDENTIKEY Authentication Server 3.x updates (i.e. Identikey Server 3.1 or IDENTIKEY
IDENTIKEY Authentication Server 3.20 – Product Guide 223
18. Licensing
Authentication Server 3.3) are valid for this version of IDENTIKEY Authentication Server.
18.3. Obtaining and Loading a License Key
The Maintenance Wizard will guide you through the process of requesting and loading a License Key. However, if
for some reason it is not possible to complete the licensing at installation time, the Administration Web Interface
can be used to obtain and load a License Key for a Component. This process must be completed for each
IDENTIKEY Authentication Server instance, and requires an active internet connection to open the Manage
IDENTIKEY Authentication Server page.
To view license information for a client component, log in to the Administration Web Interface and navigate to Cli-
ents > List. Doing so will display the Client List. Note that not all clients require a license:
Procedure 8: Viewing license information of an IDENTIKEY Authentication Server component
1. Log in to the Administration Web Interface.
2. Navigate to Servers > List. Doing so will display the Server List of IDENTIKEY Authentication Server.
3. Click on the required server to view its property pages.
4. Click the License tab. Doing so will display the licensing properties of that server component.
Note
To obtain a license key, an active internet connection is required.
Procedure 9: Obtaining and loading a license key
1. Log in to the Administration Web Interface.
2. Navigate to Servers > List. Doing so will display the Server List of IDENTIKEY Authentication Server.
3. Click on the required server to view its property pages.
4. Click the License tab. Doing so will display the licensing properties of that server component.
5. Click the Get License Key button.
Doing so will launch a browser window, with the OneSpan license activation page loaded. Some details of
the component will be entered automatically for you.
6. Enter any other required information into the web page.
7. When the License Key has been generated, right-click on the Right-click and save the file to disk link.
Select the option to save the link – save it with a .dat extension (e.g. license.dat).
The license file will also be emailed to you.
8. The download of your License Key file should begin. Keep note of where you save the file, and its name.
9. Once the download is complete, return to the Licensing page of the server component for which you are
obtaining a license.
10. Click on the Load License Key button.
11. Browse to the download location of the License Key you downloaded earlier and select the .dat License
Key file.
IDENTIKEY Authentication Server 3.20 – Product Guide 224
18. Licensing
12. To enable IDENTIKEY Authentication Server features which are newly licensed, tick the Automatically
enable new functionality checkbox. All new functionality will be enabled, and will be available to admin-
ister in the Administration Web Interface. Note that some features, such as the RADIUS communicator, will
not be enabled if they were disabled when the license was loaded. They will still have to be enabled
manually.
If the Automatically enable new functionality checkbox is not ticked, new functionality will only be enabled
after logging off the Administration Web Interface, and logging back on.
13. Click on Upload to load the License Key from the file into the component record.
14. Any new functionality may need to be enabled in other IDENTIKEY Authentication Server instances in your
system. If so, follow this procedure for each one.
Note
Whenever you change or update the server license key, you need to reconfigure IDENTIKEY Authentic-
ation Server replication!
IDENTIKEY Authentication Server 3.20 – Product Guide 225
19. Monitoring
19. Monitoring
This chapter describes the Performance and System Monitoring functions in IDENTIKEY Authentication Server.
IDENTIKEY Authentication Server 3.20 – Product Guide 226
20.1. Performance Monitoring
Performance Monitoring allows you to monitor specific parts of IDENTIKEY Authentication Server processing to pro-
duce useful performance statistics.
Performance Monitoring is disabled, enabled, and managed using the Configuration Utility.
IDENTIKEY Authentication Server uses Filters to define what to monitor; the different supported plugins are used to
control how to deliver that data. Filters are applied to all possible output plugins.
The Help button of the Configuration Utility's Performance Monitoring section contains detailed information on the
syntax of filters.
20.1.1. Filters
The Performance Monitoring tool uses filters to determine which specific parts of IDENTIKEY Authentication
Server processing should be monitored.
A filter must consist of the name of a performance transaction. You can specify a single performance transaction,
or you can use the asterisk (*) wildcard to identify a group of transactions.
IDENTIKEY Authentication Server 3.20 – Product Guide 227
Image 71: Adding Filter in Performance Monitoring
In the IDENTIKEY Authentication ServerConfiguration Utility click Add to define a filter. In the Transaction Filter box ,
a filter can be added by entering a pattern. This pattern must consist of the name of a performance transaction.
The positioning of the asterisk determines what performance transactions will be filtered. For example:
n *administration.logon -by placing the asterisk at the beginning , all performance transactions
that end in administration.logon will be monitored
n *administration* -by placing an asterisk at the beginning and at the end, everything related to
administration will be monitored
n identikey.scenario.signature* -by placing the asterisk at the end, all performance trans-
actions starting with identikey.scenario.signature will be monitored
n identikey*logon -by placing the asterisk in the middle, all performance transactions starting with
identikey and ending with logon will be monitored.
You can find a list of available performance transactions via the Help of the Configuration Utility, as well as in the
IDENTIKEY Authentication Server Administrator Reference.
IDENTIKEY Authentication Server 3.20 – Product Guide 228
20.1.2. Plugins
The Performance Monitoring tool uses several plugins in order to define its output.
CSV Plugin
The CSV Plugin allows you to define a comma-separated variable (.csv) file to write the results to. To enable
the CSV plugin, click Enable CSV Plugin in the Performance Monitoring Tool.
Counter Plugin
To enable the counter plugin, click Enable Counter Plugin in the Performance Monitoring Tool.
The counter plugin records statistics on transactions specified in the filter. The counters are available via
SNMP on both Windows and Linux. When using the Counter Plugin, you can only filter on Performance Mon-
itoring Counters. The Counter Plugin does not filter on scenario counters.
The Counter Plugin will generate data relating to the number of times certain transactions have been carried
out, and relevant timing information for those transactions. The SNMP server on which the Counter Plugin
enters the data is the one running on IDENTIKEY Authentication Server.
The counter data can be viewed using SNMP.
Note
For the counter plugin to work, system monitoring must be enabled (see 21.1. System Monitoring).
ARM4 Plugin
This plugin allows you to define an Application Response Measurement application.
20.2. Health Check
IDENTIKEY Authentication Server offers a dedicated health check to monitor the VASCO IDENTIKEY Authentication
Server service and check if the service is available and working properly. The health check endpoint is enabled by
default using port 8889 and /health as URL extension. If you send an HTTP GET request to this endpoint, one of the
following HTTP status codes is returned in a log file, according to the service status:
n Succeeding health check request: HTTP 200
n Failed health check request: HTTP 503
n Non-supported URL: HTTP 404
IDENTIKEY Authentication Server 3.20 – Product Guide 229
21.1. System Monitoring
IDENTIKEY Authentication Server supports application level system monitoring with SNMP. This feature allows you
to monitor IDENTIKEY Authentication Server processing to provide notifications when specific events occur.
System Monitoring is performed based on the IDENTIKEY Authentication Server audit messages and their contents,
and creates an alert when specified messages appear. These alerts, or targets, are sent via text messages, e-
mails, or SNMP traps. To apply system monitoring, the IDENTIKEY Authentication Server System Monitoring feature
must be enabled. Use the IDENTIKEY Authentication Server configuration interfaces to configure, enable, or disable
system monitoring. In the Configuration Utility go to Monitoring and click Enable System Monitoring, in the Admin-
istration Web Interface go to System > Server Configuration > System Monitoring. The Configuration Utility is also
used to define which audit messages to monitor, along with the notification destination and format.
Note
When enabling system monitoring via the Configuration Utility, IDENTIKEY Authentication Server needs to be
restarted - the system automatically enforces this operation. When enabling system monitoring via the Admin-
istration Web Interface, IDENTIKEY Authentication Server does not need to be restarted.
Filters help system administrators monitor critical events as they occur, rather than making them search through
an extensive list of audit logs to locate potentially critical system events.
21.1.1. Filters
System Monitoring requires filters to specify which IDENTIKEY Authentication Server events / audit messages
should be monitored. Filter details must include a/an:
n Name
n Target, specifying which notification method is to be used
n Audit message type to monitor
n Specific field
n Condition
n Value for the specified field
The fields listed herein are monitored from the vdsauditmsg table, which stores audit messages.
21.1.2. Targets
The System Monitoring tool requires one or more targets to be defined to specify the output format. The available
target formats are:
n SMS
n E-mails
n SNMP-traps
IDENTIKEY Authentication Server 3.20 – Product Guide 230
The following table lists the different required information for each target.
Table 17: Target requirements
Target Required Information
SNMP n a name
n SNMP type – Inform, TRAP, TRAPV2c
n Host IP address
n Security name for SNMPV3
n Authentication protocol type
n Authentication Secret
n Privacy type
n Privacy secret
SMS n a name
n a mobile phone number
Email n a name
n a source email address
n a target email address
n a subject line
Note
When you configure SNMP targets, make sure to set both the Authentication type AND the Privacy type for a
complete trap configuration in the IDENTIKEY Authentication Server Configuration Utility, i.e. you cannot set
a privacy type without setting an authentication type.
Only the following combinations for SNMP communication are valid:
n Without authentication and privacy (both set to None).
n With authentication, but without privacy.
n With authentication and privacy.
21.1.2.1. Best Practices: System Monitoring with SNMP Targets
When using IDENTIKEY Authentication Server System Monitoring, OneSpan recommends defining SNMP targets for
the following IDENTIKEY Authentication Server events:
n IDENTIKEY Authentication Server Errors. For this type of events, OneSpan recommends defining an audit fil-
ter that extracts all error audit messages.
n Locked DIGIPASS users. For this type of events, a filter should be defined that extracts all audit messages
with the audit code ‘W-011003’.
n Failed administrative logons. For this type of events, a filter should be defined that extracts all audit mes-
sages with the audit code ‘F-004001’.
n Replication failures. For this type of events a filter should be defined that extracts all audit messages with
the audit code ‘F-003001’ or ‘F-003002’.
IDENTIKEY Authentication Server 3.20 – Product Guide 231
22. User Dashboard
22. User Dashboard
The User Dashboard of the IDENTIKEY Authentication Server Administration Web Interface allows you to easily man-
age, monitor, and troubleshoot DIGIPASS user accounts, with the Dashboard tab providing an overview of the most
important user settings in one place. The information shown in this tab includes general user settings, a list of
recent users and DIGIPASS activities, used clients, and assigned DIGIPASS authenticator for a selected user. To edit
these settings or view full details, switch to the corresponding tabs in the Administration Web Interface. For more
information, refer to 22.1. Working with the User Dashboard.
In addition, the User Dashboard facilitates user-specific report creation and provides easy access to audit mes-
sages for a single user or DIGIPASS activity record. For more information, refer to 22.1.7. Generating Reports via
the Dashboard Tab, 22.3. Generating Reports via the Reports Tab, and 22.2. View Audit Message Page.
22.1. Working with the User Dashboard
The Dashboard tab of the User Properties page in the Administration Web Interface provides an overview of the
most important settings for the selected user such as user information, assigned DIGIPASS, used clients, and
recent activity.
22.1.1. Account Overview
This section lists information about the user account:
n Last authentication
n Account status
n Expires
n Static password
n Administration privileges
To view all user account settings or to change settings, switch to the User Account tab of the User Properties page.
22.1.2. Policy Overrides
This section lists the policy override settings for the user:
n Local authentication
n Back-end authentication
n Offline authentication
n Max Days Between Authentications
n Virtual DIGIPASS
n Virtual signature
To change the policy override settings, switch to the Policy Overrides tab of the User Properties page.
IDENTIKEY Authentication Server 3.20 – Product Guide 232
22. User Dashboard
22.1.3. User Info
This section contains general user information:
n User name
n Phone
n Mobile
n Email address
n Description
To view all user info settings or to change settings, switch to the User Account tab of the User Properties page.
22.1.4. Assigned DIGIPASS
This section contains information about the five last used DIGIPASS assigned to the selected user, and includes the
following:
n Serial number
n DIGIPASS type
n Status
n Active applications
n Virtual Mobile Authenticator (VDP)
For a complete list of assigned DIGIPASS, switch to the Assigned DIGIPASS tab of the User Properties page.
22.1.5. Recent Activity
This section shows the most recent activity records for the user.
To view all recent activity records, switch to the Recent Activity tab of the User Properties page.
22.1.6. Used Clients
This section lists the five last client components used by the selected user, and includes the following:
Table 18: Dashboard Used Clients - Displayed Fields
Field Contents
Time The time at which the last activity for the relevant used client was recorded.
Client Type States which type the used client is.
Click the client identifier to go to the Client Properties page for this client.
IDENTIKEY Authentication Server 3.20 – Product Guide 233
22. User Dashboard
Table 18: Dashboard Used Clients - Displayed Fields (continued)
Field Contents
Policy ID The policy related to the used client.
Click the policy ID to go to the Policy Properties page for this policy.
To view all recently used clients, switch to the Recent Activity tab of the User Properties page.
22.1.7. Generating Reports via the Dashboard Tab
The QUICK REPORT button in the User Dashboard of the selected user allows an administrator to quickly generate
a user-specific report. By default, IDENTIKEY Authentication Server generates a Detailed Activity Summary report.
For more information about generating reports via the User Dashboard, refer to the IDENTIKEY Authentication
Server Administrator Guide, Section "User Dashboard".
For more information about reports, refer to 14. Reporting. For more information about generating user-specific
reports via the Reports tab in the User Properties page, refer to 22.3. Generating Reports via the Reports Tab.
22.1.8. Recent User Activities
Recent user activities include results from various user operations and IDENTIKEY Authentication Server events:
n Authentication
n Authenticating a user
n EMV-CAP Authentication
n Authenticating using EMV-CAP
n Signature Validation
n Authenticating a signature
n Generating a virtual signature
n Provisioning
n Registering
n Activating
n Assigning
n Registering using DIGIPASS Software Advanced Provisioning Protocol (DSAPP)
n Activating using DIGIPASS Software Advanced Provisioning Protocol (DSAPP)
n Getting activation data using DIGIPASS Software Advanced Provisioning Protocol (DSAPP)
n Registering using Multi-Device Licensing (MDL)
n Adding a device using Multi-Device Licensing (MDL)
n Activating using Multi-Device Licensing (MDL)
n Administration
n Assigning a DIGIPASS authenticator
n Moving a user
n Unassigning a DIGIPASS authenticator
n Disabling a user
n Enabling a user
IDENTIKEY Authentication Server 3.20 – Product Guide 234
22. User Dashboard
n Unlocking a user
n Enabling offline authentication
n Disabling offline authentication
n Resetting the last authentication time
n Setting user expiration
n Updating a user
n Linking a user
n Setting a password
n Resetting a password
n Setting user permissions
n Creating user attributes
n Deleting user attributes
n Deleting offline data
n Events
n No DIGIPASS authenticator was found for Auto-Assignment.
n A user account has been locked.
When a client application is configured to use auto- unlock and the user account becomes
locked,the audit information also displays the date and time when the end user can authenticate
again to auto-unlock their user account.
The number of recent user activity records displayed can be restricted by time and number. This means that activ-
ity records older than a certain time threshold are excluded from the result. Furthermore, only a total number of
records are returned. The limits are configured in the global server configuration. This means that they apply to all
IDENTIKEY Authentication Server instances within a replicated environment.
22.1.9. Recent DIGIPASS Activities
Recent DIGIPASS activities include results from various DIGIPASS operations and IDENTIKEY Authentication Server
events:
n Authentication
n Authenticating a user
n EMV-CAP Authentication
n Authenticating using EMV-CAP
n Signature Validation
n Authenticating a signature
n Generating a virtual signature
n Provisioning
n Registering
n Activating
n Assigning
n Registering using DIGIPASS Software Advanced Provisioning Protocol (DSAPP)
n Activating using DIGIPASS Software Advanced Provisioning Protocol (DSAPP)
n Getting activation data using DIGIPASS Software Advanced Provisioning Protocol (DSAPP)
n Registering using Multi-Device Licensing (MDL)
IDENTIKEY Authentication Server 3.20 – Product Guide 235
22. User Dashboard
nAdding a device using Multi-Device Licensing (MDL)
nActivating using Multi-Device Licensing (MDL)
n Administration
n Assigning a DIGIPASS authenticator
n Moving a DIGIPASS authenticator
n Unassigning a DIGIPASS authenticator
n Resetting a PIN
n Forcing a PIN change
n Resetting a DIGIPASS Application
n Activating a DIGIPASS Application
n Deleting a DIGIPASS Application
n Resetting activation data
n Enabling a Server PIN
n Disabling a Server PIN
n Setting a DIGIPASS expiration
n Unbinding a device
n Updating a DIGIPASS authenticator (e.g. changing expiration, grace period, ...)
n Binding a device
n Deactivating a DIGIPASS Application
n Unlocking a DIGIPASS Application
n Testing an application
n Setting an event counter
n Events
n A Virtual Mobile Authenticator delivery failed.
n The quota of remaining uses for a Backup Virtual Mobile Authenticator has been spent.
The number of recent DIGIPASS activity records displayed can be restricted by time and number. This means that
activity records older than a certain time threshold are excluded from the result. Furthermore, only a total number
of records are returned. The limits are configured in the global server configuration. This means that they apply to
all IDENTIKEY Authentication Server instances within a replicated environment.
22.2. View Audit Message Page
The View Audit Message page displays the details of a single audit message for the user or DIGIPASS recent activity
on a single page and provides access to all relevant audit message fields. To view this page, the administrator
must have the View Audit Information administration privilege; if this applies, they can access the View Audit Mes-
sage page by selecting the relevant audit message code displayed in the Recent Activity page.
The number of audit records for recent user or DIGIPASS activities displayed can be restricted by time and number.
This means that audit records older than a certain time threshold are excluded from the result. Furthermore, only a
total number of records are returned. The limits are configured in the global server configuration. This means that
they apply to all IDENTIKEY Authentication Server instances within a replicated environment.
IDENTIKEY Authentication Server 3.20 – Product Guide 236
22. User Dashboard
22.3. Generating Reports via the Reports Tab
The Reports tab of the User Properties page provides a list of reports that can be run via this tab. That list is a sub-
set of the global list of reports in IDENTIKEY Authentication Server, where the currently viewed user is automatically
preselected in the run-time query definition. For a complete list of reports that are by default available in this tab,
refer to the IDENTIKEY Authentication Server Administrator Reference, Section "Reporting".
This subset can be retrieved from the global report set by filtering the reports according to different sets of defin-
ition criteria (see Table 19: Report Definition Criteria).
Table 19: Report Definition Criteria
Group Level Possible Report Type Data Source
User
DIGIPASS n List Analysis
n Detailed Analysis
n Distribution Analysis
Organizational Unit Users + audit
Organizational Unit n List Analysis DIGIPASS + audit
Using these criteria to create a customized report allows you to also include this report in the results list.
IDENTIKEY Authentication Server 3.20 – Product Guide 237
23. Auditing and Tracing
23. Auditing and Tracing
The OneSpan audit system enables you to audit the operations IDENTIKEY Authentication Server performs and
provides high-level details on these operations. This audit system consists of a number of auditing modules which
save audit messages to a specific format (e.g. text file or database), and the Audit Viewer application, which can
open, display, and filter audit messages from various sources.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), ensure that GDPR-compliance
is met when auditing with IDENTIKEY Authentication Server by:
n Encrypting the database and connections to it if database auditing is used.
n Encrypting the folder or disk containing the audit text file if text file auditing is used.
n Encrypting the Windows Event Logs folder (also on remote machines if remote logging is enabled).
n Encrypting the Linux syslog folder (also on remote machine if remote logging is enabled).
For more information about GDPR, refer to the IDENTIKEY Authentication ServerGeneral Data Protection Regu-
lation Compliance Guide.
Image 72: Audit System Overview
Audit messages are primarily generated by IDENTIKEY Authentication Server and include RADIUS accounting data.
These messages may be recorded by a number of different methods:
n Windows Event Log (to be viewed in the Event Log Viewer)
n Syslog (in Linux environments)
n Text file
n ODBC-compliant database
IDENTIKEY Authentication Server 3.20 – Product Guide 238
23. Auditing and Tracing
Live auditing, where audit messages are captured and passed directly to the Audit Viewer application as a live
feed, is also available.
Auditing output from the IDENTIKEY Authentication Server can be configured using the Configuration Utility. For
more information, refer to the IDENTIKEY Authentication Server Administrator Reference, Section "Configuration".
23.1. Audit Viewer
The Audit Viewer can retrieve messages from several different sources and display audit messages from each in
separate windows. Audit messages may be filtered by message type, date and time, or the contents of specific
fields.
Note
On some versions of Windows, the use of this utility will require an administrator login to the IDENTIKEY Authentic-
ation Server host. Because of this, you may be prompted to either:
n Confirm that the utility should be run as an administrator.
n Enter valid administrator credentials for the IDENTIKEY Authentication Server host.
The purpose of either prompt is to elevate your privileges to those required by the utility you are attempting to
run. If you cannot elevate your privileges, the utility will run in an underprivileged state, which will likely result in
unexpected behavior.
IDENTIKEY Authentication Server 3.20 – Product Guide 239
23. Auditing and Tracing
Image 73: Audit Viewer
23.2. Audit Message Types
IDENTIKEY Authentication Server logs the following types of audit messages:
Table 20: Audit Message Types
Type Description
Error The message contains details about a system, configuration, licensing or some internal error. Errors do not include
normal processing events such as failed logins.
Warning Warning messages contain details about potential problems within the system. This could include details such as a
failed connection attempt to a database
Information Informational messages provide details about events within the system that need to be recorded but do not indic-
ate errors or potential errors.
Success Success messages contain details about processing events that were correctly processed. This may include suc-
cessful authentications or successful administration commands.
Failure Failure messages contain details about processing events that failed. This may include rejected authentications, or
administration actions that failed.
RADIUS RADIUS accounting message.
For a list of audit messages, refer to the IDENTIKEY Authentication Server Administrator Reference.
23.2.1. Active Directory Auditing
Active Directory auditing may be enabled and configured to record access and modifications to DIGIPASS-related
data used by the IDENTIKEY Authentication Server.
For more information, refer to the Active Directory auditing section in the IDENTIKEY Authentication Server Admin-
istrator Guide.
23.3. Secure Auditing
An option is available to enable Secure Auditing during the installation of IDENTIKEY Authentication Server.
Secure Auditing provides the following:
IDENTIKEY Authentication Server 3.20 – Product Guide 240
23. Auditing and Tracing
Integrity protection
With Secure Auditing, IDENTIKEY Authentication Server uses a non-viewable encrypted signature added to
each line of an audit file, or each row of an audit data store. This prevents any operator from making untrace-
able manual changes to the audit file.
Independent verification
Each audit file or data store can be verified using the Secure Auditing Verification Tool.
Non-repudiation
Secure Auditing verifies audit data by comparing each signed line or row of audit data with the previous and
subsequent entries in the audit data.
Secure Auditing can also work with a Hardware Security Module (HSM) (see 8.2. Licensing and Configuration).
23.3.1. How Secure Auditing Works
Secure Auditing adds a cryptographic signature to each audit message written to the output. The cryptographic sig-
nature relates each message entry to the previous and subsequent entries. External auditors can cryptographically
verify each signature and verify that no lines have been manually deleted or added from the audit information; the
relationship between the entries is verifiable using the Secure Auditing Verification Tool.
Each audit message entry belongs to an epoch, which is a period delimited either by time or by number of audit
messages. At the end of each epoch the encryption key is changed. A message is written to the audit file to indic-
ate that an epoch has ended, and another message is written to indicate that a new epoch has begun. The length
of processing for each epoch is defined during initial configuration. A new epoch always begins at midnight. A mes-
sage is written to the output to indicate the beginning and end of an epoch. Each epoch message contains inform-
ation required by the Secure Auditing Verification Tool to decrypt the signatures for that epoch. This information is
located at the start of each epoch message.
Warning
OneSpan does not support multiple IDENTIKEY Authentication Server instances writing Secure Auditing data to
the same audit database. As such, for environments running multiple instances of IDENTIKEY Authentication
Server, each instance that uses Secure Auditing should have its own audit database.
23.4. Deleting Audit Data
Audit data that are older than a given period, defined by your organization, or that are no longer required for the ori-
ginal purpose, can be deleted from the IDENTIKEY Authentication Server audit database. This can be done via the
Maintenance Wizard, or via the Administration Web Interface and the Delete Audit Data Wizard.
IDENTIKEY Authentication Server 3.20 – Product Guide 241
23. Auditing and Tracing
The Audit Message Import/Export wizard allows you to import audit data from one source and re-import it to a text
file or ODBC database. This wizard is launched from the main interface of the Maintenance Wizard.
With the Delete Audit Data Wizard you can either delete audit records immediately, or schedule a task for the dele-
tion; you can also configure this to be a recurring task and delete audit records at regular intervals.
For more information on task management and more detailed instructions for audit message export and task-
based erasure of audit data, refer to the IDENTIKEY Authentication Server Administrator Guide.
23.5. Tracing
IDENTIKEY Authentication Server also offers tracing for troubleshooting purposes. The level of tracing used by
IDENTIKEY Authentication Server can be configured using the Configuration Utility. Tracing messages will be recor-
ded to a text file, and the trace log files can be rotated according to their age or size.
Note
OneSpan strongly recommends using the tracing feature only for troubleshooting and disable tracing when
IDENTIKEY Authentication Server is used in production mode to enhance server performance.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), you need to ensure that
GDPR-compliance is met by encrypting the folder or disk storing the trace file, if tracing is used.
Refer to the Tracing section in the IDENTIKEY Authentication Server Administrator Reference for more information
and for specific instructions on configuring tracing for IDENTIKEY Authentication Server.
IDENTIKEY Authentication Server 3.20 – Product Guide 242
24. Message Delivery Component (MDC)
24. Message Delivery Component (MDC)
The Message Delivery Component (MDC) service accepts one-time password (OTP) notifications and other mes-
sages from IDENTIKEY Authentication Server and interfaces with SMS, email, voice, or Push Notification gateways
to relay those messages to a user’s phone or email address. Push notifications can be forwarded via an on-prem
DIGIPASS Gateway or OneSpan Notification Gateway.
Warning
If your organization is impacted by the General Data Protection Regulation (GDPR), note that the SEAL protocol
used for communication with IDENTIKEY Authentication Server must be SSL enabled in the Message Delivery
Component Configuration Utility to be GDPR-compliant.
If the Email Delivery option is selected, ensure that the gateway server is configured to use SSL and TLS encryp-
tion.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
You can enable client and server SSL certificates over the link between MDC and IDENTIKEY Authentication Server,
and you can customize rotation of the trace log file (if desired).
IDENTIKEY Authentication Server supports the following delivery methods via MDC:
n SMS
n Email
n Voice (a text-to-speech service)
n Push notifications
Several templates are defined for each of these delivery methods. For more information about these templates,
refer to the IDENTIKEY Authentication Server Administrator Guide and the IDENTIKEY Authentication
Server Administrator Reference, Section "Message Delivery Component Message Settings".
MDC can be used for a number of different functional areas within IDENTIKEY Authentication Server. The delivery
methods available depend on the functionality available within each functional area.
n Virtual Mobile Authenticator (one-time password)
n Virtual signature
n DIGIPASS activation data (sends DIGIPASS activation QR code via email only)
n System monitoring notification
n Configuration test message
Multiple gateways may be configured, and optionally grouped by a chosen MDC profile name. These gateway
definitions can be managed via the MDC Configuration Utility . For more information, refer to the IDENTIKEY
Authentication Server Administrator Guide, Section "Message Delivery Component Configuration via GUI".
IDENTIKEY Authentication Server 3.20 – Product Guide 243
24. Message Delivery Component (MDC)
24.1. Gateway Definition
Each gateway is tied to a specific delivery method and protocol. A gateway definition defines a gateway as having
a server type of either:
n Primary
n Backup
The server type of a gateway helps determine how the Message Delivery Component performs load-balancing, fail-
over, and/or failback.
Multiple gateways may be configured, and optionally grouped by a chosen MDC profile name. These gateway
definitions can be managed via the MDC Configuration Utility . For more information, refer to the IDENTIKEY
Authentication Server Administrator Guide, Section "Message Delivery Component Configuration via GUI".
24.2. Gateway Types (by Protocol)
IDENTIKEY Authentication Server supports three types of gateway format. Each of these gateway formats uses a
specific connection protocol:
n HTTP/HTTPS (voice, SMS, or Push Notification)
n SMPP 3.4 rev. 1.2 (SMS only)
n SMTP/SMTPS (e-mail only)
IDENTIKEY Authentication Server also supports exporting and importing gateway definition settings to and from
XML.
24.3. MDC profiles
Gateway definitions can be grouped using MDC profiles. MDC profiles are independent of gateway type or delivery
method. MDC will select the highest-ranked, enabled and available gateway with the specified MDC profile name,
and use it for message delivery. If an MDC profile name is not specified, then the highest-ranked, enabled and
available gateway for the specified delivery method will be used.
IDENTIKEY Authentication Server 3.20 – Product Guide 244
25. Upgrading IDENTIKEY Authentication Server and Migrating Server Data
25. Upgrading IDENTIKEY Authentication Server and Migrating
Server Data
The upgrade mechanism of IDENTIKEY Authentication Server ensures that you can upgrade to the most recent
IDENTIKEY Authentication Server version with minimum server downtime and minimum impact on the availability
of your authentication services.
During a rolling upgrade, i.e. when upgrading multiple IDENTIKEY Authentication Server instances in environments
where authentication services absolutely cannot be taken offline, authentication services remain available through-
out the upgrade process. For more information about rolling upgrade and the various scenarios, refer to the
IDENTIKEY Authentication Server Administrator Guide.
The upgrade process involves the following steps:
1. Upgrading IDENTIKEY Authentication Server software
2. Updating static server configuration
3. (OPTIONAL) Migrating from Software Security Module (SSM) to Hardware Security Module (HSM)
4. Migrating server data
While steps 1 to 3 require individual servers to be down, authentication services are available during server data
migration in step 4, and are also available on other server instances during a rolling upgrade.
Warning
When upgrading from IDENTIKEY Authentication Server version 3.14 or an earlier supported version using the
embedded PostgreSQL database, the PostgreSQL database remains on the disk, and to be GDPR-compliant,
OneSpan recommends to either delete the database, or to encrypt the file or disk if the old database is kept.
For more information on GDPR, refer to the IDENTIKEY Authentication Server General Data Protection Regulation
Compliance Guide.
25.1. Upgrading IDENTIKEY Authentication Server Software and Updating Static Server Con-
figuration
During IDENTIKEY Authentication Server software upgrade and static configuration update, the installed product
components and all static server settings are updated. At this point, authentication requests cannot be processed
on the server instance that is being upgraded.
IDENTIKEY Authentication Server data stored in the storage subsystem, such as DIGIPASS or user data, will be
migrated in a separate step, to avoid prolonged server downtime. For more information, see 25.3. Migrating
Server Data.
IDENTIKEY Authentication Server 3.20 – Product Guide 245
25. Upgrading IDENTIKEY Authentication Server and Migrating Server Data
25.2. Migrating from Software Security Module (SSM) to Hardware Security Module (HSM)
When configuring IDENTIKEY Authentication Server in the course of an upgrade, if an SSM is configured for this
instance of IDENTIKEY Authentication Server and if the storage used is an ODBC storage, you can migrate to a Hard-
ware Security Module (HSM). On Microsoft Windows, you can migrate to a SafeNet HSM. On Linux, SafeNet and
Thales nShield HSMs are supported.
Warning
The migration from an SSM to an HSM deployment is not revertible; migrating back to an SSM deployment is not
possible.
For more information about the HSM migration process, see 8.4. HSM Migration. For instructions to migrate to an
HSM, refer to the IDENTIKEY Authentication Server Installation Guide for Windows or the IDENTIKEY Authentication
Server Installation Guide for Linux.
25.3. Migrating Server Data
Upgrading IDENTIKEY Authentication Server will most likely involve a database schema update. Therefore, as soon
as the server has been upgraded, server data from the previous installation such as DIGIPASS and user data, needs
to be migrated to match the new schema.
Server data is continuously migrated while the already-upgraded IDENTIKEY Authentication Server is running. This
means that the data store contains both migrated and non-migrated data until data migration has been com-
pleted.
To ensure that authentication services remain available at all times, data is migrated using two complementary
mechanisms:
n On-the-fly data migration
On-the-fly data migration means that data is migrated on demand whenever IDENTIKEY Authentication
Server receives a request (e.g. an authentication request) and accesses server data records. Only data
records required to process the request are migrated, whereas data records which are newly created or
have already been migrated will not be processed (a second time).
Note
On-the-fly data migration is only triggered upon updating or reading a data record; it is not initiated by
queries (listing several data records).
n Task-based data migration
IDENTIKEY Authentication Server 3.20 – Product Guide 246
25. Upgrading IDENTIKEY Authentication Server and Migrating Server Data
In addition, to systematically migrate all server data from the old installation, you need to start or schedule
a data migration task using the Administration Web Interface. The data migration task runs in the
background and migrates all database records one-by-one to the new schema, except for server data
which has already been migrated.
Each server data record is migrated only once, either on-the-fly or by the data migration task.
Note
If a data record cannot be migrated for any reason, it will be specially marked. Such marked data records will be
blocked and cannot be accessed regularly anymore, but only queried and deleted. To use such blocked data
records again, you need to manually inspect and recover them.
25.3.1. Considerations for Migrating Server Data
The following sections contain recommendations for and additional information about server data migration.
25.3.1.1. Data migration and server performance
n Running the data migration task may impact IDENTIKEY Authentication Server performance. Therefore,
OneSpan recommends that you schedule the task according to your user load and performance require-
ments. You can monitor the task progress in the task list of the Administration Web Interface.
25.3.1.2. Data migration and replication
n In environments with multiple IDENTIKEY Authentication Server instances, the data migration task can run
on only one IDENTIKEY Authentication Server instance at a time. The migrated server data is then rep-
licated to all other databases that are used.
n For an IDENTIKEY Authentication Server setup with several servers in replication on IDENTIKEY
Authentication Server-level, the data migration tasks have to be run on every other server after
the first server has successfully completed the data migration task. Once replication is complete
on the first server it is run on all other existing instances of IDENTIKEY Authentication Server.
n For IDENTIKEY Authentication Server environments with replication on database level (like for
instance mirroring), the first instance of IDENTIKEY Authentication Server processes the entire
data migration. For all other instances the OneSpan IDENTIKEY Authentication Server service must
be restarted once the data migration task has been completed on the first instance, i.e. the
instance where the data migration task was started.
n When upgrading multiple IDENTIKEY Authentication Server instances, to avoid replication queue issues,
the data migration task needs to run after all server instances have been upgraded, and when replication
between all instances is in place again. This applies to environments where the IDENTIKEY Authentication
Server instances are configured to replicate data changes between them.
For more information about replication, see 17.7. Replication.
IDENTIKEY Authentication Server 3.20 – Product Guide 247
25. Upgrading IDENTIKEY Authentication Server and Migrating Server Data
25.3.1.3. Miscellaneous
n While server data migration is still in progress, the result of a query command may be incomplete and may
include not-yet migrated data.
n While server data migration is still in progress, you cannot switch IDENTIKEY Authentication Server to
migration mode (and use it with Data Migration Tool).
n Should a restart of the IDENTIKEY Authentication Server service be required while the data migration task
is in progress, the task will automatically resume when the service is available again.
For more information about data migration after a rolling upgrade, refer to the IDENTIKEY Authentication Server
Administrator Guide . For instructions to create and schedule a data migration task, refer to the IDENTIKEY
Authentication Server Windows Installation Guide or the IDENTIKEY Authentication Server Linux Installation Guide.
IDENTIKEY Authentication Server 3.20 – Product Guide 248
Index
Index
A B
accepted domain 64 Back-End Authentication 84
Activation Code 102, 125 DP110 Provisioning Scenarios 119
activation completed notification 104 Grace Period 73
activation delayed notification 104 LDAP protocol 87
Active Directory LDAP protocol and Active Directory, site awareness 87
administrative permissions 206 Password Autolearn 86
administrative tasks 145 provisioning 105
Back-End Authentication 87 Software DIGIPASS Registration 125
Back-End Authentication, site awareness 87 Stored Static Password 85
domain root 202 back-end protocol 63, 84, 105, 111, 117, 183, 185
overview 45, 200 back-end server
permissions required 205 RADIUS server 35
User 60-61, 87 record 45, 86
Users and Computers Extension (ADUCE) 148 Backup Virtual DIGIPASS 22
Active Directory, storage Usage Guidelines 175
domain name resolution 59 BLOB
administration DIGIPASS 44
administrative tasks
ADUCE 148 C
ODBC and Active Directory comparison 145
cache persistence 220
administrator types 206
centralized database
components 41
reporting 192
interfaces 145
Certificate Authority 48
privileges 162
challenge
Administration Client Component 178
Access-Challenge mechanism 35
ADUCE 41, 87, 108, 145, 148, 162, 206
generating a challenge 74
Asymmetric Encryption 49
Challenge/Response
Audit System 41, 238
1-Step 74
Audit Viewer 42, 62, 145, 154, 178, 238-239
1-Step Challenge/Response 74, 185
auditing
2-Step 74
live auditing 239
2-Step Challenge/Response 74
live connection audit method 239
challenge generation 74
Auditing
time/event-based 170
database schema (ODBC) 194
types of DIGIPASS 16
importing and exporting Audit Messages 242
CHAP 32, 47, 87, 93-94, 138
authentication process 53
Check Digit 171, 183, 185
authenticators
Citrix Web Interface 28, 54, 76, 179
auto-assignment and maker-checker authorization 65, 166
Classless Inter-Domain Routing (CIDR) notation 54, 99, 123
auto-assignment
Communicator 28
and maker-checker authorization 65, 166
component records 44
overview 166
connection handling 215
auto-unlock 163
Context Menu 149
Autolearn
conversion, User ID/domain 158
Password Autolearn 85-86, 94, 159, 161, 183, 185
creating users via dynamic user registration (DUR) 157
IDENTIKEY Authentication Server 3.20 – Product Guide
Index
Index
cryptographic signature DIGIPASS Applications
Secure Auditing 241 time/event-based 170
CSV DIGIPASS authenticators
plugin 229 authenticators with keypad 17
authenticators without keypad 18
D DIGIPASS card readers 19
software DIGIPASS authenticators 20
data fields 16, 96, 136, 158, 171, 194
virtual DIGIPASS authenticators 22
Data Migration Tool 248
DIGIPASS expiration time 80, 169
data stores
DIGIPASS Gateway
domain name resolution 56-59
push-notification-based authentication 75
IDENTIKEY Authentication Server Data Model 43
DIGIPASS start time 80, 103, 169
defaults
DIGIPASS user account
domain 61
auto-unlock 163
Deferred Signature Validation 97
domain 45
delayed activation 80, 103
accepted domain 64
activation completed notification 104
Active Directory 45, 200
activation delayed notification 104
administration privileges 162
delayed activation period 103
administrative permissions 206
delivery of Software DIGIPASS 102
Back-End servers, domain-specific 86
dictionary
default domain 61
RADIUS 83, 152
domain record 45
DIGIPASS
domain root
activation completed notification 104
Active Directory 202
activation delayed notification 104
ODBC 210
BLOB 44
master 209
delayed activation 80, 103
overview (ODBC) 208
delayed activation period 103
reporting permissions 191
expiration time 80, 169
user ID and domain resolution 56
instance 24
User ID/domain conversion 158
master activation application 25
domain name resolution 56
Multi-Device Activation 23
Active Directory (storage) 59
Multi-Device Licensing 23
ODBC 57
overview 15
ODBC with Active Directory back end 58
PIN 170
DP110
provisioning 105
Provisioning 119
Secure Channel 25
Scenarios 119
Software DIGIPASS
DUR user information synchronization 158
delivery 102
Dynamic User Registration
registration 123
provisioning 105
start time 80, 103, 169
dynamic user registration (DUR) 64, 158
Tcl Command-Line Administration 150
creating users 157
types of 16
DUR user information synchronization 158
User Account Lookup and Checks 56, 99
User Accounts 157 E
Virtual DIGIPASS 22
DIGIPASS 110 119 EAP 35, 93-94
DIGIPASS App effective settings 159, 183
push–notification-based authentication 21, 26, 75 EMV-CAP 14, 19, 29, 135-136, 142, 234-235
IDENTIKEY Authentication Server 3.20 – Product Guide
Index
Index
Evaluation License 223 Internet Information Services 38
event-based 98, 129, 167, 170, 172
Event-based DIGIPASS Applications 170 L
event counter 98-99, 101, 167, 236
LDAP
event value 172
Active Directory Back-End Authentication 87
expiration, static back-end password 161
site awareness 87
expiration, static local password 160
license key 178, 180, 222, 224
F licensing 23, 25, 68, 79, 97, 110, 112, 125-126, 135, 137, 147,
200, 220, 222, 224, 234-235, 240
Fail-over strategy Licensing
Back-End Server records 86 EMV-CAP 135
filters live auditing 239
performance monitoring 227 live connection audit method 239
functionality module (FM) Load Balancing and Failover
SafeNet 141 Hardware Security Modules 138
Local Authentication 67
G Grace Period 73
provisioning 105
General Data Protection Regulation (GDPR)
Software DIGIPASS Registration 124
database encryption, Caution notice 31
login permutations 93, 176
securing connections, Caution notice 29, 46, 133, 243
securing RADIUS connections, 29-31, 41-43, 128, 131, 150, M
Caution notice 157, 180, 208, 214, 238, 242
securing replication, Caution notice 216 maker–checker authorization
General Data Protection Regulation (GDPR), Caution notice 13 caveats 51
Grace Period 73 circumventing unassign DIGIPASS authenticator by delete,
Group Check 62, 65, 67, 84, 100, 124, 132, 183, 197 Caution notice 51
Master Domain 209
H maximum report size
reporting 194
hardserver 143
MDC Profiles 243-244
Hardware Security Module 30, 135, 137-139, 141-142, 241,
types 244
(HSM) 245
Message Delivery Component
EMV-CAP 135
profiles 243-244
functionality module (FM) 137
Message Delivery Component (MDC) 243
Load Balancing and Failover 138
Microsoft Point-to-Point Encryption (MPPE) 47, 87, 93
migrating from SSM 138, 246
migrating from SSM to HSM, Caution notice 246
migrating from SSM, Caution notice 246
Mobile Authenticator Studio, definition 21
SafeNet 141
supported models 137
VACMAN Controller HSM module 137
HTTP Basic Authentication 76, 95
I
IDENTIKEY Authentication Server
upgrading 245
inheritance 183
international character support
limitations 94
IDENTIKEY Authentication Server 3.20 – Product Guide
Index
Index
monitoring permissions
filters 227 Active Directory 205
performance 227 administrative permissions (Active Directory) 206
Performance Monitoring tool 227, 229 PIN
plugins 229 DIGIPASS authenticators with keypads 17
system monitoring 226, 230-231 DIGIPASS PIN 170
Multi-Mode 16, 21, 69 Server PIN 70
types of DIGIPASS 16 Server PIN settings 174
plugins
N performance monitoring 229
Policy
nFastServer 143
base policy vs. Base Policy, definition 182, 184
O parentless policy 182, 184
Primary Account Number 136
ODBC Primary Virtual DIGIPASS 22
administrative tasks 145 Private Key 49
domain name resolution 57 privileges, administration 162
domain name resolution with Active Directory back end 58 protocols
domain root 210 RADIUS (supported) 93
domains and organizational units 208 provisioning 105
Offline Delivery 102 Provisioning
one-time passwords (OTP) 15 DP110 119
Operator Card Set 142 Public Key 48
Organizational Units Push Notification
Active Directory 201 authentication method 26
ODBC 210 DIGIPASS App 21
record 46 DIGIPASS Gateway 75
out-of-band (OOB) authentication
push notification 75 R
Outlook Web Access 54, 69, 84-85, 179
RADIUS 31
P as a back-end server 35
Attributes 32, 186
PAP 32, 47, 87, 93 limitations 94
Parent Organizational Units securing connections 29-31, 41-43, 128, 131, 150, 157,
Active Directory 203 180, 208, 214, 238, 242
ODBC 211 supported protocols 93
password recent DIGIPASS activity 235
supported protocols 32 recent user activity 234
Password registration of Software DIGIPASS 123
expiration, back-end password 161
expiration, local password 160
password strength 159
Policy 160
RADIUS password protocols (limitations) 94
PCI-DSS 50
PEAP 35
pending operations See maker–checker authorization
performance monitoring 227
IDENTIKEY Authentication Server 3.20 – Product Guide
Index
Index
replication strength, password 159
high-load scenario, Caution notice 216 Symmetrical Encryption 49
Replication System Monitoring
Active Directory 148, 207 configuration via configuration interfaces 230
reporting events to be monitored 231
considerations 192 filters 230
features and settings 188
maximum report size 194 T
Response-Only
Tcl Command-Line Administration 150
time/event-based 170
Thales nShield 142
types of DIGIPASS 16
hardserver 143
S nFastServer 143
Time-based DIGIPASS Applications 170
SafeNet 141
Secure Auditing 240-241 U
Secure Execution Engine 143
upgrading IDENTIKEY Authentication Server
Security World 142
migrating from SSM to HSM 246
SEE Module 143
on-the-fly data migration 246
Self-Assignment 166
overview 245
serial number 24, 43, 80, 100, 112, 114, 121, 147, 166, 223, 233
server data migration 246
server data migration
software upgrade 245
after upgrade 245
static server configuration update 245
considerations 247
task-based data migration 246
data migration task 246
User Account
on-the-fly 246
DIGIPASS 157
performance considerations 247
types 144
replication on database level 247
User Account Lookup and Checks 99
replication on server level 247
user authentication
replication queue 247
overview 53
task-based 246
User Dashboard 232
Server PIN 70
user ID and domain resolution 56
settings 174
User ID/domain conversion 158
Server PIN reset 70
Users and Computers Extension (ADUCE) 148
Server PIN reset, Auto-Assignment and Self-Assign-
UTF-8
ment 70, 81, 165
encoding 95
Signature
time/event-based 170 V
types of DIGIPASS 16
site awareness, Active Directory back-end authentication 87 Verification Tool
Software DIGIPASS 20 Secure Auditing 241
delivery 102 view audit information 236
DP110 119
registration 123
SSL 48
SOAP SSL 48
SSL-specific terms 48
static passwords 29, 36, 39, 47, 104, 106, 113, 159
Stored Static Password 85
IDENTIKEY Authentication Server 3.20 – Product Guide
Index
Index
Virtual DIGIPASS 22
Backup Virtual DIGIPASS Usage Guidelines 175
factors to consider 174
limiting usage 176
login options 176
Primary and Backup 22
W
Web Basic Authentication 95
Windows Group Check 62, 65, 67, 84, 100, 124, 132, 183, 197
wireless RADIUS 34, 196
IDENTIKEY Authentication Server 3.20 – Product Guide
You might also like
- 156-215.81.20 CheckPoint CCSA Exam Practice QuestionsNo ratings yet156-215.81.20 CheckPoint CCSA Exam Practice Questions21 pages
- Symantec DLP 15.0 Install Guide For Windows100% (1)Symantec DLP 15.0 Install Guide For Windows144 pages
- IDENTIKEY Authentication Server SDK Programmer's GuideNo ratings yetIDENTIKEY Authentication Server SDK Programmer's Guide149 pages
- IDENTIKEY Authentication Server Deployment and Performance GuideNo ratings yetIDENTIKEY Authentication Server Deployment and Performance Guide49 pages
- Entrust IdentityGuard Virtual Appliance SB OCT16 WEB3 PDFNo ratings yetEntrust IdentityGuard Virtual Appliance SB OCT16 WEB3 PDF4 pages
- Guardium Data Protection - L4 Deploy - Troubleshoot - Troubleshooting Unix S-TAP Sev1 Issues - PresentationNo ratings yetGuardium Data Protection - L4 Deploy - Troubleshoot - Troubleshooting Unix S-TAP Sev1 Issues - Presentation9 pages
- C2150-606.exam.32q: Website: VCE To PDF Converter: Facebook: TwitterNo ratings yetC2150-606.exam.32q: Website: VCE To PDF Converter: Facebook: Twitter27 pages
- Human Computer Interaction - MICT 731 - Richfield Graduate Institute of Technology (Pty) LTD - Johannesburg - NotesNo ratings yetHuman Computer Interaction - MICT 731 - Richfield Graduate Institute of Technology (Pty) LTD - Johannesburg - Notes9 pages
- 3.04 - Configuration - Audit - System - v10x - LabNo ratings yet3.04 - Configuration - Audit - System - v10x - Lab23 pages
- Try Latest & Free DELL EMC DES-6322 Real Dumps0% (1)Try Latest & Free DELL EMC DES-6322 Real Dumps11 pages
- On-Premise - Seclore - Component Description - 2016No ratings yetOn-Premise - Seclore - Component Description - 20164 pages
- IBM Security Guardium Training: QuarantineNo ratings yetIBM Security Guardium Training: Quarantine12 pages
- ChangeAuditor ActiveDirectory 7.1 EventReferenceGuideNo ratings yetChangeAuditor ActiveDirectory 7.1 EventReferenceGuide69 pages
- Entrust IdentityGuard 8.1 Directory Configuration Guide100% (1)Entrust IdentityGuard 8.1 Directory Configuration Guide62 pages
- AppGate SDP-Reference Architectures 072020No ratings yetAppGate SDP-Reference Architectures 07202021 pages
- Tenable SecurityCenter 4.2 5.x DEMO - KeyNo ratings yetTenable SecurityCenter 4.2 5.x DEMO - Key1 page
- 1Y0-241 Deploy and Manage Citrix ADC With Traffic ManagementNo ratings yet1Y0-241 Deploy and Manage Citrix ADC With Traffic Management26 pages
- Guardium Architecture and Deployment - Master SkillsNo ratings yetGuardium Architecture and Deployment - Master Skills97 pages
- Pki Administration Using Ejbca and OpencaNo ratings yetPki Administration Using Ejbca and Openca5 pages
- Assessment: v14.3 Database Activity Monitoring User GuideNo ratings yetAssessment: v14.3 Database Activity Monitoring User Guide20 pages
- Qradar Support 101: Wincollect TroubleshootingNo ratings yetQradar Support 101: Wincollect Troubleshooting38 pages
- SDP101 Overview Presentation W Talktrack 022421-210316-174943No ratings yetSDP101 Overview Presentation W Talktrack 022421-210316-17494324 pages
- Attachment 14940535 2 4 - S-GATE - PresentationNo ratings yetAttachment 14940535 2 4 - S-GATE - Presentation14 pages
- Configuration of Microsoft ISA Proxy Server and Linux Squid Proxy ServerFrom EverandConfiguration of Microsoft ISA Proxy Server and Linux Squid Proxy ServerNo ratings yet
- Tech-Tok Case Study Project Documentation AirbnbNo ratings yetTech-Tok Case Study Project Documentation Airbnb23 pages
- Euro Zone Debt Worries Sink Dow Below 10,000 (Reuters) : Sell / Take Profits While You Can Since Much, Much Worse To Come!No ratings yetEuro Zone Debt Worries Sink Dow Below 10,000 (Reuters) : Sell / Take Profits While You Can Since Much, Much Worse To Come!13 pages
- SecureToken - 2 Factor Authentication SecurityNo ratings yetSecureToken - 2 Factor Authentication Security4 pages
- Cb3491 Cryptography and Cyber Security Unit 2No ratings yetCb3491 Cryptography and Cyber Security Unit 228 pages
- The 6 Business and Security Benefits of Zero Trust: White PaperNo ratings yetThe 6 Business and Security Benefits of Zero Trust: White Paper7 pages
- Resit - CST - Assessment Brief CIS7028 WRIT1-2022 - S1No ratings yetResit - CST - Assessment Brief CIS7028 WRIT1-2022 - S17 pages
- 840Dsl Fundamentals Progr Man 1217 en-USNo ratings yet840Dsl Fundamentals Progr Man 1217 en-US614 pages
- PAN-EDU-101 - Lab Manual PAN-OS 6.0 - Rev A PDF33% (3)PAN-EDU-101 - Lab Manual PAN-OS 6.0 - Rev A PDF48 pages
