Identikey Server Product Guide - Vasco
Identikey Server Product Guide - Vasco
Identikey Server Product Guide - Vasco
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>Identikey</strong> <strong>Server</strong><br />
<strong>Product</strong> <strong>Guide</strong><br />
3.0<br />
3.1
Disclaimer of Warranties and Limitations of Liabilities<br />
Disclaimer of Warranties and Limitations of Liabilities<br />
The <strong>Product</strong> is provided on an 'as is' basis, without any other warranties, or conditions, express or implied,<br />
including but not limited to warranties of merchantable quality, merchantability of fitness for a particular purpose,<br />
or those arising by law, statute, usage of trade or course of dealing. The entire risk as to the results and<br />
performance of the product is assumed by you. Neither we nor our dealers or suppliers shall have any liability to<br />
you or any other person or entity for any indirect, incidental, special or consequential damages whatsoever,<br />
including but not limited to loss of revenue or profit, lost or damaged data of other commercial or economic loss,<br />
even if we have been advised of the possibility of such damages or they are foreseeable; or for claims by a third<br />
party. Our maximum aggregate liability to you, and that of our dealers and suppliers shall not exceed the amount<br />
paid by you for the <strong>Product</strong>. The limitations in this section shall apply whether or not the alleged breach or default<br />
is a breach of a fundamental condition or term, or a fundamental breach. Some states/countries do not allow the<br />
exclusion or limitation or liability for consequential or incidental damages so the above limitation may not apply to<br />
you.<br />
Copyright<br />
Copyright © 2009 VASCO Data Security, Inc., VASCO Data Security International GmbH. All rights reserved.<br />
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any<br />
means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of<br />
VASCO Data Security Inc.<br />
RADIUS Documentation Disclaimer<br />
The RADIUS documentation featured in this manual is focused on supplying required information pertaining to the<br />
RADIUS server and its operation in the <strong>Identikey</strong> <strong>Server</strong> environment. It is recommended that further information be<br />
gathered from your NAS/RAS vendor for information on the use of RADIUS.<br />
Trademarks<br />
VASCO®, Vacman®, IDENTIKEY®, aXs GUARD, DIGIPASS®, and ® are registered or unregistered<br />
trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other<br />
countries.<br />
Document Version: 1.1
Table of Contents<br />
Table of Contents<br />
1 Overview........................................................................................................................................................ 8<br />
1.1 What is <strong>Identikey</strong> <strong>Server</strong>?.................................................................................................................................... 8<br />
1.2 What is a Digipass?............................................................................................................................................. 8<br />
1.3 Types of Digipass................................................................................................................................................ 9<br />
1.4 Structure of <strong>Identikey</strong> <strong>Server</strong>.............................................................................................................................. 14<br />
1.5 <strong>Identikey</strong> <strong>Server</strong> in a RADIUS Environment......................................................................................................... 17<br />
1.6 <strong>Identikey</strong> <strong>Server</strong> in a Web Environment.............................................................................................................. 21<br />
1.7 Administration Components............................................................................................................................... 23<br />
1.8 <strong>Identikey</strong> <strong>Server</strong> Data Model.............................................................................................................................. 26<br />
1.9 Integrating Your Systems With <strong>Identikey</strong> <strong>Server</strong>................................................................................................. 28<br />
1.10 SOAP SSL.......................................................................................................................................................... 30<br />
1.11 Available <strong>Guide</strong>s................................................................................................................................................ 32<br />
2 User Authentication Process......................................................................................................................... 34<br />
2.1 Logging in with a Digipass................................................................................................................................. 34<br />
2.2 Authentication Process Overview....................................................................................................................... 35<br />
2.3 Identifying the Component Record..................................................................................................................... 36<br />
2.4 Digipass User Account Lookup and Checks........................................................................................................ 37<br />
2.5 Local Authentication.......................................................................................................................................... 45<br />
2.6 Back-End Authentication.................................................................................................................................... 54<br />
2.7 Authorization Profiles/Attributes......................................................................................................................... 62<br />
2.8 Host Code Generation........................................................................................................................................ 62<br />
2.9 Supported RADIUS Password Protocols.............................................................................................................. 63<br />
2.10 Unsupported by <strong>Identikey</strong> <strong>Server</strong>........................................................................................................................ 64<br />
3 Signature Validation Process......................................................................................................................... 66<br />
3.1 Signing a Transaction........................................................................................................................................ 66<br />
3.2 How Do I Generate a Signature?........................................................................................................................ 66<br />
3.3 Time based signature........................................................................................................................................ 67<br />
3.4 Event Based Signature....................................................................................................................................... 67<br />
3.5 Static Signature................................................................................................................................................. 68<br />
3.6 Signature Verification Process............................................................................................................................ 68<br />
3.7 Policy Settings................................................................................................................................................... 70<br />
4 Software Digipass Provisioning..................................................................................................................... 71<br />
4.1 Software Digipass Provisioning Overview........................................................................................................... 71<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 3
Table of Contents<br />
4.2 Provisioning Scenarios....................................................................................................................................... 74<br />
4.3 DP110 Provisioning Overview............................................................................................................................ 81<br />
4.4 What are the steps in registration of a Software Digipass?................................................................................. 85<br />
4.5 What are the steps in activation?....................................................................................................................... 87<br />
4.6 Reactivation ...................................................................................................................................................... 88<br />
5 Administration Interfaces.............................................................................................................................. 89<br />
5.1 Data Administration........................................................................................................................................... 89<br />
5.2 System Administration....................................................................................................................................... 94<br />
5.3 What do I need to use?...................................................................................................................................... 95<br />
6 Digipass User Accounts................................................................................................................................ 96<br />
6.1 Digipass User Account Creation......................................................................................................................... 96<br />
6.2 Changes to Stored Static Password.................................................................................................................... 97<br />
6.3 Administration Privileges....................................................................................................................................97<br />
7 Digipass....................................................................................................................................................... 98<br />
7.1 Importing Digipass............................................................................................................................................. 98<br />
7.2 Assigning Digipass to Users............................................................................................................................... 98<br />
7.3 Digipass Record Functions............................................................................................................................... 101<br />
7.4 Digipass Programming..................................................................................................................................... 103<br />
7.5 Digipass Record Settings................................................................................................................................. 105<br />
7.6 Virtual Digipass Implementation Considerations............................................................................................... 108<br />
8 Client Components..................................................................................................................................... 111<br />
8.1 Component Types............................................................................................................................................ 111<br />
9 <strong>Server</strong> Components.................................................................................................................................... 113<br />
9.1 <strong>Server</strong> Component........................................................................................................................................... 113<br />
10 Policies....................................................................................................................................................... 114<br />
10.1 Policy Inheritance............................................................................................................................................ 114<br />
10.2 Pre-Loaded Policies......................................................................................................................................... 117<br />
11 Reporting................................................................................................................................................... 121<br />
11.1 Reporting Overview......................................................................................................................................... 121<br />
11.2 Report Definition.............................................................................................................................................. 122<br />
11.3 Standard Reports............................................................................................................................................. 125<br />
11.4 Custom Reports............................................................................................................................................... 126<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 4
Table of Contents<br />
11.5 Report Generation Process............................................................................................................................... 126<br />
11.6 Report Usage and Change Permissions............................................................................................................ 127<br />
11.7 Making Data Available to Reports..................................................................................................................... 128<br />
12 <strong>Identikey</strong> Data Store................................................................................................................................... 129<br />
12.1 Active Directory............................................................................................................................................... 129<br />
12.2 ODBC Database............................................................................................................................................... 137<br />
12.3 Sensitive Data Encryption................................................................................................................................ 148<br />
13 Licensing.................................................................................................................................................... 149<br />
13.1 Overview......................................................................................................................................................... 149<br />
13.2 Obtaining and Loading a License Key............................................................................................................... 149<br />
14 Auditing and Tracing................................................................................................................................... 150<br />
14.1 Audit System................................................................................................................................................... 150<br />
14.2 Tracing............................................................................................................................................................ 152<br />
15 Message Delivery Component..................................................................................................................... 153<br />
15.1 What is the Message Delivery Component?...................................................................................................... 153<br />
15.2 Starting the Message Delivery Component....................................................................................................... 153<br />
16 User Self Management Web Site................................................................................................................. 154<br />
16.1 What is the User Self Management Web Site?.................................................................................................. 154<br />
16.2 Customizing the User Self Management Web Site............................................................................................ 155<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 5
Illustration Index<br />
Table of Contents<br />
Image 1: GO 3...................................................................................................................................................................................................................10<br />
Image 2: GO 5...................................................................................................................................................................................................................10<br />
Image 3: GO 6...................................................................................................................................................................................................................10<br />
Image 4: DP 585...............................................................................................................................................................................................................11<br />
Image 5: DP 260...............................................................................................................................................................................................................11<br />
Image 6: DP 270...............................................................................................................................................................................................................11<br />
Image 7: DP 810...............................................................................................................................................................................................................12<br />
Image 8: DP 805...............................................................................................................................................................................................................12<br />
Image 9: DP 110...............................................................................................................................................................................................................13<br />
Image 10: Structure of <strong>Identikey</strong> <strong>Server</strong>............................................................................................................................................................................14<br />
Image 11 : SSL handshake process..................................................................................................................................................................................32<br />
Image 12 : Login Methods................................................................................................................................................................................................34<br />
Image 13: Authentication Process Overview......................................................................................................................................................................35<br />
Image 14: Name Resolution with Active Directory.............................................................................................................................................................39<br />
Image 15: Name Resolution with ODBC database.............................................................................................................................................................40<br />
Image 16 - Dynamic User Registration Process.................................................................................................................................................................44<br />
Image 17: User Account Link............................................................................................................................................................................................46<br />
Image 18: Virtual Digipass Login.......................................................................................................................................................................................49<br />
Image 19: Multiple Digipass Assignment...........................................................................................................................................................................51<br />
Image 20: The steps in Back-End Authentication for Novell eDirectory and ADAM............................................................................................................59<br />
Image 21: Steps of Signature Verification Process ...........................................................................................................................................................68<br />
Image 22: Steps of Provisioning........................................................................................................................................................................................73<br />
Image 23: Digipass for Mobile Scenario 1 process ...........................................................................................................................................................75<br />
Image 24: Digipass for Web Scenario 1 Process ..............................................................................................................................................................77<br />
Image 25: Digipass for Web Scenario 2 Process ..............................................................................................................................................................78<br />
Image 26: Digipass for Web Scenario 3 Process ..............................................................................................................................................................80<br />
Image 27: DP110 Scenario 1............................................................................................................................................................................................82<br />
Image 28: DP110 Scenario 2............................................................................................................................................................................................84<br />
Image 29: Steps of Software Digipass Registration...........................................................................................................................................................85<br />
Image 30: Steps of Software Digipass Activation...............................................................................................................................................................87<br />
Image 31: Self Assignment Process .................................................................................................................................................................................99<br />
Image 32: Auto Assignment Process ..............................................................................................................................................................................100<br />
Image 33: Manual Assignment Process ..........................................................................................................................................................................101<br />
Image 34: Policy Inheritance...........................................................................................................................................................................................114<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 6
Table of Contents<br />
Image 35: Reporting Structure........................................................................................................................................................................................121<br />
Image 36: Report Grouping.............................................................................................................................................................................................124<br />
Image 37: Report Generation Process ............................................................................................................................................................................126<br />
Image 38: Digipass Record Locations - Digipass Pool.....................................................................................................................................................132<br />
Image 39: Digipass Record Locations - Parent Organizational Unit..................................................................................................................................133<br />
Image 40: Digipass Record Locations - Individual Organizational Units...........................................................................................................................135<br />
Image 41: Domains and Organizational Units..................................................................................................................................................................137<br />
Image 42: Digipass Record Locations – Domain Root.....................................................................................................................................................139<br />
Image 43: Digipass Record Location – Parent Organizational Unit...................................................................................................................................140<br />
Image 44: Digipass Record Location s – Individual Organizational Units..........................................................................................................................141<br />
Image 45: Additional ODBC databases............................................................................................................................................................................143<br />
Image 46: Multiple <strong>Identikey</strong> <strong>Server</strong> Using Single Database............................................................................................................................................144<br />
Image 47: Replication between a Primary and Backup <strong>Identikey</strong> <strong>Server</strong>..........................................................................................................................145<br />
Image 48: Replication between Primary, Backup, and Disaster Recovery in <strong>Identikey</strong> <strong>Server</strong>..........................................................................................146<br />
Image 49: Replication between three <strong>Identikey</strong> <strong>Server</strong>s..................................................................................................................................................147<br />
Image 50: Complex <strong>Identikey</strong> <strong>Server</strong> Replication Scenario..............................................................................................................................................147<br />
Image 51: Audit System Overview...................................................................................................................................................................................150<br />
Image 52: Audit Viewer...................................................................................................................................................................................................151<br />
Image 53: User Self Management Web Site....................................................................................................................................................................154<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 7
1 Overview<br />
1.1 What is <strong>Identikey</strong> <strong>Server</strong>?<br />
Overview<br />
<strong>Identikey</strong> <strong>Server</strong> is a server product designed to support the deployment, use and administration of VASCO<br />
Digipass technology. It can be easily integrated with existing applications using a Software Developer Kit (SDK).<br />
<strong>Identikey</strong> <strong>Server</strong> provides support for the following primary functions:<br />
Digipass One Time Password Authentication<br />
Digipass Signature Validation<br />
Software Digipass Provisioning<br />
Administration and Reporting<br />
Auditing<br />
<strong>Identikey</strong> <strong>Server</strong> is designed to be easily usable with Web applications and has a Web-based Administration<br />
interface.<br />
1.2 What is a Digipass?<br />
A Digipass is a device for providing One Time Passwords and Digital Signatures to a User.<br />
A Digipass may be provided to each person whom an organization wishes to be able to log into their system using<br />
a One Time Password (OTP). The User obtains an OTP from the Digipass to use instead of, or as well as, a static<br />
password when logging in.<br />
In addition, a Digipass may be provided for the user to sign transaction data. The user enters key details of the<br />
transaction into their Digipass and receives a signature. They enter the signature into a transaction confirmation<br />
page in order to confirm that they authorize the transaction.<br />
Virtual Digipass is a mechanism where an OTP is generated by the server and sent by text message to the User's<br />
mobile phone. In this case, a physical Digipass device is not needed.<br />
A Software Digipass may be installed onto your computer, or onto a mobile device such as a Blackberry or Javaenabled<br />
mobile phone. It can be used to generate an OTP or a Signature in the same way as a physical Digipass<br />
device.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 8
1.3 Types of Digipass<br />
Overview<br />
Each Digipass is programmed with at least one Digipass Application and a unique secret. The Digipass Application<br />
uses this secret when generating One Time Passwords and Signatures.<br />
Each type of Digipass Application generates One Time Passwords or Signatures from different data, and in slightly<br />
different ways:<br />
Response Only<br />
Creates a One Time Password based on the current date and time or on the number of uses (events).<br />
Challenge/Response<br />
Creates a One Time Password (also referred to as a 'Response') based on a numerical challenge given on a login<br />
page. This may be either a challenge custom-created for the specific Digipass, or a randomly created challenge.<br />
The One Time Password may also be based on the date and time.<br />
Digital Signature<br />
Digital Signature Digipass Applications are typically used in online banking. The Digipass generates a unique code<br />
- referred to as a 'Digital Signature' - based on a number of transaction data fields entered, plus (optionally) the<br />
date and time or number of uses (events).<br />
Multi-Mode<br />
Multi-mode Digipass are Digipass that are capable of being used in all of the above modes. This setting is used<br />
mainly for Digipass for Web.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 9
1.3.2 Hardware Digipass<br />
Overview<br />
Hardware Digipass are devices specifically designed for creation of One Time Passwords and Digital Signatures.<br />
Depending on the model supplied, they may be used for Response Only, Challenge/Response and Digital Signature<br />
methods.<br />
The three basic types of hardware Digipass are:<br />
Digipass without keypads<br />
These are the simplest type of Digipass. They have a triggering mechanism - typically a button or action, such as<br />
pulling the Digipass open - which causes a One Time Password to be generated. They have only one Application,<br />
which is always Response Only.<br />
Image 1: GO 3 Image 2: GO 5<br />
Image 3: GO 6<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 10
Digipass with keypads<br />
Overview<br />
These are typically capable of supporting more than one Application, and can be programmed so that a PIN must<br />
be entered before a One Time Password or Digital Signature may be generated.<br />
Image 4: DP 585 Image 5: DP 260<br />
Image 6: DP 270<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 11
Smartcard reader Digipass<br />
Overview<br />
These provide two-factor authentication based on smartcard technology in a similar way to the above two types.<br />
The smartcard itself provides the 'secret' that is used to generate OTPs and Digital Signatures.<br />
1.3.3 Software Digipass<br />
Image 7: DP 810 Image 8: DP 805<br />
Software Digipass may be installed onto a Blackberry, Java-enabled mobile phone or other mobile device. The User<br />
then accesses a Digipass application to obtain a One Time Password or Digital Signature. They typically support<br />
Response Only, Challenge/Response or Digital Signature Digipass Applications.<br />
Distribution of Software Digipass is controlled by <strong>Identikey</strong> <strong>Server</strong> using Provisioning scenarios. See 4 Software<br />
Digipass Provisioning for more information.<br />
Digipass for Web<br />
Digipass for Web is a Java applet that runs on your internet browser. Digipass for Web can generate One Time<br />
Passwords and Digital Signatures. Digipass for Web supports the Multi-Mode Application type.<br />
Digipass for Mobile<br />
Digipass for Mobile is a Java applet that will run on your Java enabled mobile phone or Blackberry. Digipass for<br />
Mobile can generate One Time Passwords and Digital Signatures.<br />
1.3.4 Hardware/Software Digipass<br />
The Digipass 110 is currently the only Digipass available which combines the security of a hardware Digipass with<br />
the portability of a software Digipass. It consists of a secure USB stick used with a Java applet on the User's<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 12
computer. It holds the cryptographic information used in generating One Time Passwords for the User.<br />
Overview<br />
Distribution of the Java applet used with the DP 110 is handled by <strong>Identikey</strong> <strong>Server</strong> in the same way as Software<br />
Digipass. See 4 Software Digipass Provisioning for more information.<br />
1.3.5 Virtual Digipass<br />
Image 9: DP 110<br />
Virtual Digipass can be used instead of hardware Digipass tokens, or as a backup mechanism when a User has<br />
mislaid their hardware Digipass. Using Virtual Digipass means that a User may receive a One Time Password on<br />
their mobile phone via text message.<br />
There are two forms of Virtual Digipass available:<br />
Primary Virtual Digipass are treated by <strong>Identikey</strong> <strong>Server</strong> almost identically to hardware and software Digipass - a<br />
record of each Primary Virtual Digipass must be imported into the data store, and may then be assigned to a User<br />
automatically or manually. The User will typically log in with their User ID and static password, have a text<br />
message sent to their mobile phone, and then enter the One Time Password from the text message in the second<br />
stage of their login.<br />
The Backup Virtual Digipass feature allows a User to request a One Time Password sent to their mobile phone if<br />
they do not have their usual Digipass at hand. It may be limited by number of uses or days of use - eg. a User may<br />
be limited to 2 days' usage, after which they will again need to use their usual Digipass to log in.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 13
1.4 Structure of <strong>Identikey</strong> <strong>Server</strong><br />
Overview<br />
The diagram below shows the basic structure of an organization's existing applications integrated with <strong>Identikey</strong><br />
<strong>Server</strong>.<br />
Image 10: Structure of <strong>Identikey</strong> <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 14
1.4.1 Customer Web Applications<br />
Overview<br />
<strong>Identikey</strong> <strong>Server</strong> provides support for web applications through an SDK based on the standard SOAP protocol.<br />
These applications may cover operational tasks such as authentication and signature validation, provisioning of<br />
Software Digipass or administration of <strong>Identikey</strong> <strong>Server</strong>.<br />
SOAP over HTTPS is supported, versions 1.1 and 1.2. 'Document Literal' binding is used. A variety of SOAP client<br />
SDKs have been tested.<br />
1.4.2 Remote Access Clients<br />
<strong>Identikey</strong> <strong>Server</strong> supports the RADIUS protocol (according to RFC 2865) for remote network access authentication,<br />
to the same level as VACMAN Middleware 3.0. Some applications are written using RADIUS as an authentication<br />
protocol, and these applications will also be supported.<br />
The SEAL protocol is a proprietary VASCO protocol used by the VASCO authentication modules. At the time of<br />
writing this includes the Digipass Packs for Citrix Web Interface, Outlook Web Access and IIS Basic Authentication.<br />
<strong>Identikey</strong> <strong>Server</strong> supports these SEAL client applications to the same level as VACMAN Middleware 3.0.<br />
1.4.3 <strong>Identikey</strong> <strong>Server</strong><br />
The <strong>Identikey</strong> <strong>Server</strong> is a Service which receives and processes requests from the various client components. It<br />
may refer to a Back-End System for a part of the processing tasks.<br />
<strong>Identikey</strong> <strong>Server</strong> has a modular architecture incorporating the following key concepts:<br />
1.4.3.1 Communicator Modules<br />
For each protocol by which requests can be received, a Communicator module is present. Each Communicator can<br />
be enabled or disabled as preferred, subject to support in the license. The following Communicators are present:<br />
1.4.3.2 Scenario Modules<br />
SOAP (requires a license option)<br />
RADIUS (requires a license option)<br />
SEAL (does not require a license option)<br />
For each major group of functionality in the <strong>Identikey</strong> <strong>Server</strong>, a Scenario module is present. Each Scenario can be<br />
enabled or disabled as preferred, subject to support in the license. The following Scenarios are present:<br />
Authentication (requires a license option)<br />
Signature Validation (requires a license option)<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 15
1.4.4 Back-End Systems<br />
Provisioning (requires a license option)<br />
Administration (does not require a license option)<br />
Reporting (does not require a license option)<br />
Replication (does not require a license option)<br />
Administration (does not require a license option)<br />
Audit Scenarios (does not requrire a license option)<br />
Configuration (does not require a license option)<br />
Overview<br />
A Back-End System is used as an authority for user accounts and static passwords, before a user account is<br />
created in <strong>Identikey</strong> <strong>Server</strong> and the user starts to use a Digipass. In addition, for RADIUS it may be used to provide<br />
RADIUS attributes back to the RADIUS client, as <strong>Identikey</strong> <strong>Server</strong> does not provide RADIUS attribute support on its<br />
own.<br />
See 2.6 Back-End Authentication for more information.<br />
1.4.5 Database <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong> uses Active Directory or an ODBC-compliant database to store administration and configuration<br />
data.<br />
An embedded PostreSQL database is included in the installation package.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 16
1.5 <strong>Identikey</strong> <strong>Server</strong> in a RADIUS Environment<br />
Overview<br />
<strong>Identikey</strong> <strong>Server</strong> can be used in a RADIUS environment in a number of ways, depending on your company's<br />
requirements.<br />
In the following scenarios, a RADIUS Client may be a dial-up NAS (Network Access <strong>Server</strong>), firewall/VPN appliance,<br />
Wireless Access Point, or another device that uses the RADIUS protocol for user authentication. Some software<br />
applications can also use RADIUS for authentication, for example Microsoft Internet Security and Acceleration<br />
<strong>Server</strong> (ISA), and can therefore also act as RADIUS Clients.<br />
In the RADIUS protocol, 'attributes' are used for authorization and configuration of the remote access session in<br />
many cases. <strong>Identikey</strong> <strong>Server</strong> is specialized in providing strong authentication using Digipass, but is not designed<br />
to provide authorization. If authorization attributes are required, a RADIUS server product is used in conjunction<br />
with <strong>Identikey</strong> <strong>Server</strong>.<br />
1.5.1 Stand-alone: No RADIUS Attributes Required<br />
In this scenario, <strong>Identikey</strong> <strong>Server</strong> is used on its own, without a RADIUS server.<br />
<strong>Identikey</strong> <strong>Server</strong> can generally be used without a RADIUS server if:<br />
RADIUS attributes are not required<br />
One of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 17
1.5.2 Proxy Target: RADIUS <strong>Server</strong> Acts as Proxy<br />
Overview<br />
In this scenario, a RADIUS server acts as a proxy for authentication, effectively delegating the authentication<br />
process to <strong>Identikey</strong> <strong>Server</strong>. The RADIUS server provides the authorization attributes after <strong>Identikey</strong> <strong>Server</strong> has<br />
accepted the user credentials.<br />
A RADIUS server can forward authentication to <strong>Identikey</strong> <strong>Server</strong> if:<br />
The RADIUS server supports the proxying of authentication while returning attributes itself<br />
The RADIUS server can forward the authentication request using one of the supported password protocols is<br />
used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2<br />
The RADIUS server supports an Access-Challenge response from <strong>Identikey</strong> <strong>Server</strong>, if required. The Access-<br />
Challenge mechanism is used for Challenge/Response and Virtual Digipass, although it is still possible to use<br />
Virtual Digipass without that mechanism.<br />
If the RADIUS server is capable, this scenario allows <strong>Identikey</strong> <strong>Server</strong> to operate in an environment that uses<br />
certificate-based EAP protocols such as PEAP and EAP-TTLS. To make this work, the RADIUS server decrypts the<br />
user credentials into a simpler protocol before forwarding the request to <strong>Identikey</strong> <strong>Server</strong>.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 18
1.5.3 Intermediary: RADIUS <strong>Server</strong> as Back-End <strong>Server</strong><br />
Overview<br />
In this scenario, <strong>Identikey</strong> <strong>Server</strong> will forward requests to a RADIUS server in order to retrieve authorization<br />
attributes, after validating the One Time Password. It is necessary to provide a static password to the RADIUS<br />
server to achieve this. Therefore, there are two methods of implementing this:<br />
1.5.3.1 Log in with OTP Only<br />
Using this method, the User only enters their OTP (including a PIN if used). <strong>Identikey</strong> <strong>Server</strong> has to learn the static<br />
password for the User, so that when the User gives the correct OTP, it can send the static password to the RADIUS<br />
server.<br />
This method can be used if:<br />
One of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2<br />
The static passwords can be 'learnt' by <strong>Identikey</strong> <strong>Server</strong><br />
If PAP is used, <strong>Identikey</strong> <strong>Server</strong> has the ability to learn the static passwords automatically. The User has to perform<br />
at least one login with their static password – if the RADIUS server accepts the password, <strong>Identikey</strong> <strong>Server</strong> can<br />
learn it.<br />
However, if one of the other password protocols is used, this process is not possible. In that case, there are a few<br />
other ways in which the passwords can be learnt, through administrative data entry or using the User Self-<br />
Management Web Site.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 19
1.5.3.2 Log in with Password and OTP<br />
Overview<br />
Using this method, the User enters their static password and OTP at each login. <strong>Identikey</strong> <strong>Server</strong> validates the OTP<br />
and if correct, forwards the static password to the RADIUS server.<br />
This method can be used if:<br />
The PAP password protocol is used, because CHAP and MS-CHAP hash the password and OTP together<br />
inseparably<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 20
1.6 <strong>Identikey</strong> <strong>Server</strong> in a Web Environment<br />
1.6.1 Soap Integration<br />
Overview<br />
<strong>Identikey</strong> <strong>Server</strong> has a SOAP module that can be used to integrate <strong>Identikey</strong> <strong>Server</strong> with web applications. The<br />
<strong>Identikey</strong> <strong>Server</strong> SOAP interface allows the following <strong>Identikey</strong> <strong>Server</strong> functions to be integrated into web<br />
applications:<br />
User Authentication<br />
Signature validation<br />
Software Digipass Provisioning<br />
Administration<br />
Reporting<br />
1.6.2 IIS Module<br />
In an IIS Web environment, <strong>Identikey</strong> <strong>Server</strong> can also use a component that plugs into Internet Information Services<br />
(IIS) to intercept authentication requests. This component, the IIS Module, verifies the credentials with <strong>Identikey</strong><br />
<strong>Server</strong> first. Normally this means verification of the One Time Password (OTP). If the OTP is valid, the static<br />
password is given back to IIS as if the user had entered it, and the normal web site authentication process<br />
completes the login.<br />
To enable verification by <strong>Identikey</strong> <strong>Server</strong> it is necessary to provide a static password, typically the Windows<br />
password, to IIS. Therefore, there are two methods of implementing this:<br />
1.6.3 Log in with OTP only<br />
Using this method, the User only enters their OTP (including a PIN if used). <strong>Identikey</strong> <strong>Server</strong> has to learn the static<br />
password for the User, so that when the User gives the correct OTP, it can give the static password back to IIS.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 21
Overview<br />
<strong>Identikey</strong> <strong>Server</strong> has the ability to learn the static passwords automatically if they are Windows passwords. The<br />
User has to perform at least one login with their static password – if this password is validated by Windows,<br />
<strong>Identikey</strong> <strong>Server</strong> can learn it.<br />
The same process can also be used if the static passwords are held in a RADIUS server – however, the <strong>Identikey</strong><br />
<strong>Server</strong> license must have RADIUS support activated for this to be enabled.<br />
This process is not possible if the static passwords are not Windows or RADIUS passwords. In that case,<br />
administrative entry is required for the passwords.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 22
1.6.4 Log in with Password and OTP<br />
Overview<br />
Using this method, the User enters their static password and OTP at each login. <strong>Identikey</strong> <strong>Server</strong> validates the OTP<br />
and if correct, returns just the static password to IIS.<br />
This method may be necessary when the static passwords are not Windows passwords, for example they may be<br />
Novell passwords. It also may be suitable if you do not want <strong>Identikey</strong> <strong>Server</strong> to store your users' Windows<br />
passwords (although they are strongly encrypted).<br />
1.7 Administration Components<br />
1.7.1 Web Administration<br />
A web-based administration application is provided with <strong>Identikey</strong> <strong>Server</strong> to enable administrators to carry out the<br />
majority of administration functions for the system. The Web Administration package allows administrators to<br />
perform tasks such as:<br />
Administer User accounts<br />
Administer Digipass<br />
Define the organizational structure<br />
Manage Policies<br />
Create and run reports<br />
Manage Client components<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 23
Manage and Configure the <strong>Identikey</strong> <strong>Server</strong><br />
Overview<br />
The Web Administration application uses the <strong>Identikey</strong> <strong>Server</strong>'s SOAP administration interface to manage data.<br />
1.7.2 Digipass Extension for Active Directory Users and Computers<br />
An extension to Active Directory Users and Computers is available. This extension allows administration of Digipass<br />
User accounts and Digipass records where <strong>Identikey</strong> <strong>Server</strong> uses Active Directory as its data store.<br />
1.7.3 The Audit System<br />
1.7.3.1 The Audit Viewer<br />
1.7.4 Reporting<br />
The Audit System tracks operations carried out by <strong>Identikey</strong> <strong>Server</strong>. Each operation generates audit messages that<br />
are written to either a text file or a database.<br />
Audit information can be used to generate reports, for example, the number of failed authentications over a certain<br />
period. Audit information can also be used by <strong>Identikey</strong> <strong>Server</strong> system administrators to monitor system<br />
performance, or suspicious activity.<br />
System administrators can use the Audit Viewer program to view Audit information. It allows System administrators<br />
to filter the audit information to make it easier to view and understand. The Audit Viewer also allows you to view<br />
audit information from different sources.<br />
Using the Audit Viewer information helps system administrators to troubleshoot effectively, and to keep track of<br />
significant events in the system.<br />
The Web Administration package contains a reporting module. This module contains the tools required to run a set<br />
of standard reports and to create and run custom reports.<br />
Reports may be based on User account and Digipass data as well as audit data. Formatting templates can be used<br />
to convert the output into the preferred format, using XSLT.<br />
1.7.5 Digipass TCL Command-Line Administration<br />
An extension to TCL is used for command-line administration tasks. The full power of TCL scripting can be used in<br />
order to automate bulk or regular administration tasks. A stand-alone TCL interpreter is also provided so that this<br />
functionality can be used where there is no TCL environment present already.<br />
The TCL extension uses the <strong>Identikey</strong> <strong>Server</strong> to manage the data store. It uses the SEAL protocol to communicate<br />
with the <strong>Identikey</strong> <strong>Server</strong>.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 24
1.7.6 <strong>Identikey</strong> <strong>Server</strong> Configuration<br />
Overview<br />
The <strong>Identikey</strong> <strong>Server</strong> uses a local XML text file to store certain configuration settings. These can be managed using<br />
a graphical user interface program.<br />
There is also a Configuration Wizard program available to carry out certain maintenance tasks such as changing<br />
the IP address of the server.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 25
1.8 <strong>Identikey</strong> <strong>Server</strong> Data Model<br />
Overview<br />
<strong>Identikey</strong> <strong>Server</strong> can use either an ODBC database (including the embedded PostgreSQL database) or Active<br />
Directory as its data store. The data model will vary slightly between ODBC and Active Directory stores.<br />
1.8.1 Digipass record<br />
The following kinds of record are stored in the <strong>Identikey</strong> <strong>Server</strong> data store:<br />
A Digipass record must exist in the data store for each Digipass in use. This record contains:<br />
Information about the Digipass (eg. serial number and model)<br />
The names and programming parameters of Applications in the Digipass<br />
The status of various options (eg. Digipass lock)<br />
Some of the information in this record is encrypted together in what is called the 'Digipass Blob'. There is one<br />
'Blob' per Application.<br />
1.8.2 Digipass User account record<br />
Each User who will be logging in using Digipass authentication will require a Digipass User account. The Digipass<br />
User account record contains information needed by <strong>Identikey</strong> <strong>Server</strong> such as authentication settings. A Digipass<br />
must be assigned to a Digipass User account before it can be used for authentication.<br />
Administrative privileges are assigned to Digipass User accounts and therefore a Digipass User account is needed<br />
for each administrator.<br />
1.8.3 Component record<br />
1.8.4 Policy record<br />
Component records are created to represent:<br />
<strong>Identikey</strong> <strong>Server</strong>s<br />
Authentication, Signature and Provisioning client components<br />
Administration client components<br />
They are used for the following main purposes:<br />
For clients, to indicate that it is permitted to process a request from that client and to specify a Policy (see<br />
below) to be used<br />
For RADIUS Clients, to hold the Shared Secret<br />
To hold a License Key for <strong>Identikey</strong> <strong>Server</strong>s and IIS Modules<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 26
Overview<br />
Policies specify various settings that affect the request handling processes. Each request is handled according to a<br />
Policy that is identified by the applicable Component record.<br />
There are many Policy settings including the following examples:<br />
Whether Local and/or Back-End authentication should be used<br />
Whether various automatic management features should be used<br />
The Digipass Application types required<br />
Backup Virtual Digipass settings<br />
1.8.5 Back-End <strong>Server</strong> record<br />
1.8.6 Domain record<br />
A Back-End <strong>Server</strong> record is required when a RADIUS or LDAP server is to be used by <strong>Identikey</strong> <strong>Server</strong> for<br />
authentication. It is possible to create more than one Back-End <strong>Server</strong> record, for fail-over purposes. You can also<br />
allocate different Back-End <strong>Server</strong>s for different user domains.<br />
Domains form the basis for the Organizational Structure in an ODBC database. Where <strong>Identikey</strong> <strong>Server</strong> uses Active<br />
Directory as its data store, the standard Active Directory Domains are used instead.<br />
Active Directory<br />
<strong>Identikey</strong> <strong>Server</strong> operates within the pre-existing Active Directory domain and Organizational Unit structure. Each<br />
Digipass User and Digipass must belong to a domain in Active Directory.<br />
User IDs must be unique within a domain, but may be repeated between domains.<br />
While Digipass User account and Digipass records can belong to any domain, a single domain is identified during<br />
installation as the Digipass Configuration Domain. This domain is used to store the Component, Policy and Back-<br />
End <strong>Server</strong> records. It is also used as a default domain for user lookup, when no domain is specified.<br />
ODBC Database<br />
Domains perform the following functions:<br />
allow different user groups to be separated<br />
provide the ability to limit administrator activities to the administrator's own domain (delegated administration)<br />
allocate unassigned Digipass records to different Domains, for example to mirror the geographic location of the<br />
devices<br />
Each Digipass User and Digipass must belong to a domain. One domain is identified as the Master Domain – this<br />
will be the default domain when none is specified. In addition, administrators in the Master Domain can be given<br />
rights to access data in all domains, where other administrators are limited to data in their own domain.<br />
User IDs must be unique within a domain, but may be repeated between domains. Digipass serial numbers must<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 27
e unique in the database.<br />
1.8.7 Organizational Unit record<br />
Overview<br />
Organizational Units, like Domains, are handled differently depending on whether the <strong>Identikey</strong> <strong>Server</strong> uses Active<br />
Directory or an ODBC database as its data store.<br />
Active Directory<br />
Where <strong>Identikey</strong> <strong>Server</strong> uses Active Directory as its data store, the standard Active Directory Organizational Units<br />
are used instead.<br />
Digipass User accounts and Digipass records are normally stored in Organizational Units or the Users container. A<br />
special container called Digipass-Pool is created during installation to hold unassigned Digipass, although they can<br />
be located in Organizational Units instead.<br />
Administration duties may be assigned to administrators per Organizational Unit, in the same way that regular user<br />
administration is delegated at that level.<br />
ODBC Database<br />
Where <strong>Identikey</strong> <strong>Server</strong> uses an ODBC database as its data store, Organizational Units allow further<br />
compartmentalisation of Digipass User accounts, Digipass records and administration duties. Organizational Units<br />
are included to:<br />
provide the ability to limit administrator activities to the administrator's own Organizational Unit (delegated<br />
administration)<br />
allocate unassigned Digipass records to different Organizational Units, for example to mirror the geographic<br />
location of the devices<br />
Digipass User accounts and Digipass records may belong to an Organizational Unit, but this is not mandatory.<br />
1.9 Integrating Your Systems With <strong>Identikey</strong> <strong>Server</strong><br />
1.9.1 SOAP Interfaces<br />
SOAP interfaces are provided to support the following functions:<br />
User Authentication<br />
Signature Validation<br />
Software Digipass Provisioning<br />
Administration<br />
Reporting<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 28
1.9.2 RADIUS<br />
You need to acquire the SDK for SOAP for further information.<br />
Overview<br />
RADIUS support is present for authentication (Access-Requests) using PAP, CHAP, MS-CHAP and MS-CHAP2.<br />
MPPE keys are generated for MS-CHAP and MS-CHAP2.<br />
If you have an existing RADIUS <strong>Server</strong>, <strong>Identikey</strong> <strong>Server</strong> can use it as a Back-End System in order to retrieve<br />
RADIUS attributes from it. Alternatively, you can use the RADIUS <strong>Server</strong> as an authority to permit dynamic creation<br />
of user accounts in <strong>Identikey</strong> <strong>Server</strong> and verification of static passwords.<br />
1.9.3 Custom Back-End Integration<br />
You can write your own plug-in Engine to attach <strong>Identikey</strong> <strong>Server</strong> to your own back end system. This would be used<br />
primarily as an authority to permit dynamic creation of user accounts in <strong>Identikey</strong> <strong>Server</strong> and for verification of<br />
static passwords.<br />
Refer to the SDK Overview <strong>Guide</strong> for further information.<br />
1.9.4 Back-End Integration<br />
There are a number of systems that can be used as Back-Ends to <strong>Identikey</strong> <strong>Server</strong>. These back-ends can be used<br />
as an authority on authentication data.<br />
The following back-ends can be used:<br />
Microsoft Active Directory<br />
Microsoft ADAM<br />
Novell e-Directory<br />
Refer to 2.6 Back-End Authentication for further information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 29
1.10 SOAP SSL<br />
1.10.1 What is SSL?<br />
Overview<br />
SSL stands for Secure Sockets Layer, which is a cryptographic protocol that provides secure communications over<br />
the Internet for e-mail, web browsing and, in this case, connection of two web-based applications via SOAP.<br />
SSL is the method by which a client can obtain a secure connection to a SSL-enabled server. The SSL-enabled<br />
server can identify itself to the client in a trusted manner before any information is passed between the client and<br />
the SSL-enabled server.<br />
1.10.2 Terms Used in SSL<br />
Some of the terms used in describing the function of SSL are specific to SSL and cryptography. Listed below are<br />
some of the terms used in this chapter, and what they mean:<br />
1.10.3 How Does SSL work?<br />
Handshake Procedure - The client machine and the SSL-enabled server establish a trusted and secure<br />
connection before any sensitive information is passed between them<br />
Certificate - The certificate in this context is an encrypted file attached to a message.<br />
Certificate Authority - a trusted third party used to issue the certificates. Each browser will have a list of<br />
trusted Certificate Authorities it can use to check against the signature on a certificate.<br />
Public Key - A key used to encrypt and decrypt information that is known to the SSL-enabled server and clients<br />
that use it.<br />
Private Key - A key known only to the SSL-enabled server that is used to decrypt information.<br />
Symmetrical Encryption - encryption that uses only one key to encrypt and decrypt information.<br />
Asymmetric Encryption - encryption that uses two keys to encrypt and decrypt information.<br />
1. A client initiates a connection using a handshake procedure. The client connects to an SSL-enabled server<br />
(the server), requesting a secure connection.<br />
2. The server sends back an encrypted certificate which usually contains the server name, the Certificate<br />
Authority and the server's public key.<br />
3. The client decrypts the certificate using the server's public key. The client checks the Certificate Authority<br />
against its browser's list of trusted Certificate Authorities.<br />
4. The client then encrypts a random number using the server's public key and sends this back to the server.<br />
This will be the secret that the client and server use to encrypt information passed between them.<br />
5. The server then decrypts the random number using the private key. The nature of the public and private<br />
keys is that information encrypted with the public key can only be decrypted by the private key.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 30
6. Information encrypted using the generated secret is passed between the client and server.<br />
If any part of the handshake procedure fails the whole handshake procedure will fail.<br />
1.10.4 SSL, SOAP and <strong>Identikey</strong> <strong>Server</strong><br />
Overview<br />
If you want to write SOAP interfaces for <strong>Identikey</strong> <strong>Server</strong>, the server side of SSL is mandatory. The SOAP client<br />
must utilize SSL to verify the server when attempting to connect.<br />
When setting up the SOAP Communication Protocol on the <strong>Identikey</strong> <strong>Server</strong> Configuration application, you can<br />
specify whether the client certificate is required:<br />
Never - the client certificate is never required.<br />
Optional - the client certificate is optional<br />
Required - The client certificate is required<br />
Required - Signed Address Only - The <strong>Server</strong> must include its IP address in the certificate. The client will<br />
match this IP address against that of the server it is connecting to. If they don't match the handshake will fail.<br />
Similarly, the client certificate must include the IP address of the client. The <strong>Server</strong> will check the IP address<br />
from the client certificate against the client it is establishing a connection with, and the handshake will fail if<br />
the two IP addresses don't match.<br />
The <strong>Identikey</strong> <strong>Server</strong> Configuration application provides a test SSL certificate. The test SSL certificate is time<br />
limited so it will expire after a period of time. When the test SSL certificate expires you can recreate it from the<br />
configuration application. Alternatively purchase an SSL certificate with a longer expiry period.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 31
Image 11 : SSL handshake process<br />
Overview<br />
The <strong>Identikey</strong> <strong>Server</strong> Configuration application SOAP Communication protocol page also contains a check box<br />
labelled Re-Verify on Re-Negotiation. Check this box to force the connection between SOAP and the <strong>Identikey</strong><br />
<strong>Server</strong> to be re-verified each time a connection is established. Please note that this may cause problems with<br />
performance and so should not be checked unless absolutely necessary.<br />
1.11 Available <strong>Guide</strong>s<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 32
The following <strong>Identikey</strong> <strong>Server</strong> guides are available:<br />
<strong>Product</strong> <strong>Guide</strong><br />
Overview<br />
The <strong>Product</strong> <strong>Guide</strong> will introduce you to the features and concepts of <strong>Identikey</strong> <strong>Server</strong> and the various options you<br />
have for using it.<br />
Getting Started <strong>Guide</strong><br />
The Getting Started <strong>Guide</strong> will lead you through a standard setup and testing of key <strong>Identikey</strong> <strong>Server</strong> features.<br />
Windows Installation <strong>Guide</strong><br />
Use this guide when planning and working through an installation of <strong>Identikey</strong> <strong>Server</strong> in a Windows environment.<br />
Linux Installation <strong>Guide</strong><br />
Use this guide when planning and working through an installation of <strong>Identikey</strong> <strong>Server</strong> in a Linux environment.<br />
Administrator Reference<br />
In-depth information required for administration of <strong>Identikey</strong> <strong>Server</strong>. This includes references such as data attribute<br />
lists, backup and recovery and utility commands.<br />
Performance and Deployment <strong>Guide</strong><br />
Contains information on common deployment models and performance statistics.<br />
Help Files<br />
Context-sensitive help accompanies the Administration Web Interface and Digipass Extension for Active Directory<br />
Users and Computers.<br />
<strong>Identikey</strong> <strong>Server</strong> SDK Programmers <strong>Guide</strong><br />
In-depth information required to develop using the SDK.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 33
2 User Authentication Process<br />
2.1 Logging in with a Digipass<br />
User Authentication Process<br />
The diagram below shows a typical login process for the three basic login methods supported by <strong>Identikey</strong> <strong>Server</strong>.<br />
Image 12 : Login Methods<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 34
2.2 Authentication Process Overview<br />
<strong>Identikey</strong> <strong>Server</strong> Authenticates logins in two basic ways:<br />
Using information from its data store ('local' authentication)<br />
Asking a Back-End system for verification of information ('back-end' authentication)<br />
User Authentication Process<br />
The exact authentication process used by <strong>Identikey</strong> <strong>Server</strong> will vary depending on settings in the applicable Policy<br />
and Digipass User account. The diagram below shows the basic process followed when authenticating a Digipass<br />
User login.<br />
Image 13: Authentication Process Overview<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 35
2.3 Identifying the Component Record<br />
The component making an authentication request will be identified using:<br />
User Authentication Process<br />
Component Type – A name provided by the SOAP application, or a fixed name such as RADIUS Client, Citrix<br />
Web Interface, Outlook Web Access or Administration Program<br />
Location – the source IP address of the request<br />
The component lookup and verification processes are a little different according to the type of component, as<br />
outlined below.<br />
2.3.1 RADIUS Client Component Check<br />
For a RADIUS Client, the following component checks are made:<br />
Component Record exists<br />
A Component record for the RADIUS Client must exist, otherwise the request is discarded without responding:<br />
Type = RADIUS Client<br />
Location = the source IP address of the request OR if there is no RADIUS client at the specified location,<br />
Location = default<br />
Shared Secret is set<br />
The Component record must have a Shared Secret value set, otherwise the request is discarded without<br />
responding.<br />
Any RADIUS Client which does not have an explicit Component record will be handled using the “default” RADIUS<br />
Client Component if it exists.<br />
2.3.2 IIS Module Component Check<br />
For an IIS Module Component the following component checks are made:<br />
Component Record exists<br />
A Component record for the IIS module must exist, otherwise the request is discarded without responding:<br />
Type = IIS module<br />
Location = the source IP address of the request<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 36
2.4 Digipass User Account Lookup and Checks<br />
<strong>Identikey</strong> <strong>Server</strong> performs a number of checks before proceeding to local authentication.<br />
2.4.1 User ID and Domain Resolution<br />
User Authentication Process<br />
In <strong>Identikey</strong> <strong>Server</strong>, Digipass User accounts are identified using a User ID and a Domain, not just a User ID. There<br />
are a few ways to do this:<br />
2.4.1.1 Windows Name Resolution<br />
In Windows environments, there are a few ways to provide these details when logging in:<br />
Using NT4-style domain qualification in front of the User ID: DOMAIN\userid<br />
Using User-Principal-name (e.g. userid@domain)<br />
With separate User ID and Domain fields (this is not possible using RADIUS)<br />
When Digipass User accounts correspond to Windows user accounts, the Windows Name Resolution feature can<br />
be used to support these three login formats. With ODBC or an embedded database, it is optional whether to user<br />
Windows Name Resolution or not. However, if the Windows Name Resolution process is enabled and fails, the<br />
login is rejected. Therefore, a login with a User ID that does not correspond to a Windows user account will be<br />
rejected.<br />
With this feature enabled, Windows is used to resolve the NT4-style and User-Principal-Name User ID formats.<br />
Windows Name Resolution is enabled using the <strong>Identikey</strong> <strong>Server</strong> Configuration program. Click the Configure<br />
Advanced Settings button on the ODBC Connection tab to get the Advanced Settings dialog; check the Use<br />
Windows User Name Resolution checkbox.<br />
2.4.1.2 Simple Name Resolution<br />
When Windows Name Resolution is not used, the following formats are available:<br />
Using a similar format to User-Principal-Name: user@domain<br />
With separate User ID and Domain fields<br />
If the user@domain format is used for the User ID, the <strong>Identikey</strong> <strong>Server</strong> will look for a Domain record with the name<br />
given after the @. If the Domain is found, the @domain part will be stripped from the User ID before the<br />
authentication process continues. If it is not found, the User ID will be left as user@domain, and no Domain will be<br />
identified. In that case, the Default Domain processing will be used, as described next.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 37
2.4.1.3 Default Domain<br />
User Authentication Process<br />
Using either Windows or Simple Name Resolution, if none of the above formats are used, only the User ID is given,<br />
with no Domain qualification. It is still necessary to identify the Domain in order to look up the Digipass User<br />
account.<br />
The Default Domain can be configured in the following ways:<br />
In the Policy record, the Default Domain field can be set. If this is set, it will be used when no Domain has<br />
been identified by the Windows or Simple Name Resolution.<br />
When the Policy has no Default Domain set, the Master Domain will be used.<br />
2.4.1.4 Active Directory User Account<br />
When Active Directory is used as the data store, Digipass User accounts are always attached to Active Directory<br />
User accounts. Therefore, if an authentication request is received for a User who does not have an account in<br />
Active Directory, the request is rejected.<br />
This is not mandatory for an ODBC or embedded database.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 38
2.4.1.5 Summary – Active Directory<br />
User Authentication Process<br />
The full process of User ID and Domain name resolution is illustrated in the following diagram, for the case where<br />
Active Directory is the data store:<br />
Image 14: Name Resolution with Active Directory<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 39
2.4.1.6 Summary – ODBC Database<br />
The full process of User ID and Domain name resolution is illustrated in the following diagram.<br />
Image 15: Name Resolution with ODBC database<br />
User Authentication Process<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 40
2.4.2 Windows Group Check (optional)<br />
User Authentication Process<br />
Specific Windows Groups can be selected for authentication by the <strong>Identikey</strong> <strong>Server</strong> when all Users are Windows<br />
accounts. This Windows Group Check feature might be used when:<br />
Deploying Digipass in stages. Users are not required to log in using a Digipass until they are put into a<br />
Windows group. They can be put into the group in manageable stages.<br />
Two-factor authentication is needed only for access to sensitive data, which has been granted to certain Users<br />
(for example, administrators). Only this group of people will require Digipass, and will be authenticated by the<br />
<strong>Identikey</strong> <strong>Server</strong>. Other Users will be authenticated by another authentication method.<br />
Most Users will have Digipass and be permitted to log in to the system, but some Users should not be<br />
authenticated under any circumstances.<br />
Authentication is needed for the live Audit Viewer connection to the <strong>Identikey</strong> <strong>Server</strong>, when using Active<br />
Directory as the data store. The Group Check can be used to limit which users are allowed to connect, for<br />
example to the Domain Admins group.<br />
When the Group Check is active, Users who are in one of the defined groups go through the full authentication<br />
process. However, there are a few Group Check Modes that control the outcome for Users who are not in one of<br />
the groups. The Group Check Mode is defined in the Policy.<br />
One or more Windows Group names must be defined in a Group List in the Policy. Group membership is checked<br />
within the User's own domain only, therefore these Groups must exist in each domain where there are Users who<br />
need to be included in a Group.<br />
2.4.2.1 'Pass Back' Mode<br />
Important Note<br />
When the Group Check is used, if the Group Check fails, the login will fail. This will occur for a<br />
user who is unknown to Windows.<br />
The following Group Check Modes are available:<br />
The full name in the Policy property sheet for this mode is:<br />
Pass requests for users not in listed groups back to host system<br />
The <strong>Identikey</strong> <strong>Server</strong> does not handle authentication for Users who are not in one of the defined groups. These<br />
Users are handled by the host system (eg. IIS). In effect, this means that they do not need to have Digipass User<br />
accounts and they do not need to use a Digipass to log on. As soon as the Group Check indicates that the User is<br />
not to be handled, authentication processing stops and the 'not handled' result is returned.<br />
This mode is suitable for staged deployment of Digipass and for the case where only certain Users need strong<br />
(Digipass) authentication.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 41
2.4.2.2 'Reject' Mode<br />
2.4.2.3 'Back-End' Mode<br />
The full name in the Policy property sheet for this mode is:<br />
Reject requests for users not in listed groups<br />
User Authentication Process<br />
The <strong>Identikey</strong> <strong>Server</strong> rejects authentication immediately for Users who are not in one of the defined groups.<br />
This mode is suitable for restricting which Users are permitted to log in.<br />
The full name in the Policy property sheet for this mode is:<br />
Use only Back-End Authentication for users not in listed groups<br />
This mode can be used when Back-End Authentication is set up (see 2.6 Back-End Authentication).<br />
The <strong>Identikey</strong><br />
<strong>Server</strong> will just use Back-End Authentication for Users who are not in one of the defined groups. For example, if<br />
RADIUS Back-End Authentication is used, the job of authenticating Users not in the defined groups is delegated to<br />
the RADIUS server. No lookup will be carried out for the Digipass User account, and no further Local<br />
Authentication will be carried out.<br />
Back-End Authentication will be used for the out-of-group Users even if the Policy setting for Back-End<br />
Authentication is set to None. In that case, the in-group Users would be authenticated only by Local<br />
Authentication, while the out-of-group Users would be authenticated only by Back-End Authentication. However, it<br />
is necessary to define the Back-End Protocol Policy setting.<br />
This mode is suitable for staged deployment of Digipass and for the case where only certain Users need strong<br />
(Digipass) authentication.<br />
2.4.3 Digipass User Account Lookup<br />
The <strong>Identikey</strong> <strong>Server</strong> checks that the User attempting to log in has a Digipass User account in the <strong>Identikey</strong> <strong>Server</strong><br />
data store. The User ID and Domain Resolution performed earlier determines the search criteria to look up the<br />
Digipass User account.<br />
If a Digipass User account is found, the Disabled and Locked indicators are checked. If either is set to Yes, the<br />
authentication request is rejected immediately.<br />
If no Digipass User account is found, then Policy settings will determine whether the <strong>Identikey</strong> <strong>Server</strong> continues<br />
processing or rejects the authentication request:<br />
If Local Authentication is required, a Digipass User account must exist. It is only possible to proceed if the<br />
Dynamic User Registration feature is enabled. This is explained further below.<br />
If Local Authentication is not required, authentication processing can proceed without a Digipass User<br />
account.<br />
If the Local Authentication Policy setting is None, no Local Authentication is required. If it is set to<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 42
Digipass/Password or Digipass Only, Local Authentication is required.<br />
2.4.4 Dynamic User Registration<br />
User Authentication Process<br />
Dynamic User Registration (DUR) allows Digipass User accounts to be created automatically when their<br />
credentials are validated by Back-End Authentication. The correct static password will be sufficient to permit a<br />
Digipass User account to be created. DUR saves the administrative work of manually creating or importing Digipass<br />
User accounts.<br />
It is typically used in conjunction with:<br />
the Digipass Auto-Assignment feature, which will assign the next available Digipass to the new Digipass User<br />
account as it is created, or<br />
the Digipass Self-Assignment feature, which will allow the new User to assign a Digipass to their account as<br />
part of their login process<br />
For more details on these Digipass assignment features, see 7 Digipass.<br />
In order to control the creation of new accounts, DUR can be used with:<br />
the Windows Name Resolution feature (mandatory for Active Directory). This will prevent more than one<br />
Digipass User account being created for the same Windows User account, when they use different User ID<br />
formats to log in<br />
the Windows Group Check feature, so that a staged creation of Digipass User accounts and assignment of<br />
Digipass is achieved<br />
A typical DUR process using Auto-Assignment and the Windows Group Check is illustrated below.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 43
Image 16 - Dynamic User Registration Process<br />
User Authentication Process<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 44
2.5 Local Authentication<br />
User Authentication Process<br />
Local Authentication is a term used to describe the <strong>Identikey</strong> <strong>Server</strong> authenticating a User based on information in<br />
its data store. Typically the Digipass One Time Password is required, but in other cases a static password may be<br />
sufficient.<br />
The Local Authentication Policy setting indicates whether to perform Local Authentication, and if so, whether a<br />
static password is permitted. This setting is overridden by the same setting in the Digipass User account, unless<br />
that has the value Default. However, this setting in the Digipass User account would typically be used only for rare<br />
special case Users.<br />
Using the Windows Group Check in Back-End Mode, this setting can be overridden. If a User is not in the list of<br />
groups, no Local Authentication will be performed.<br />
The possible values for the Local Authentication setting are as follows:<br />
None<br />
No Local Authentication will take place.<br />
Digipass/Password<br />
A Digipass One Time Password or static password may be verified. As a general rule, until a User starts to use a<br />
Digipass, they may continue to authenticate with their static password.<br />
Digipass Only<br />
A Digipass One Time Password must be verified. Users without Digipass will not be able to log in. However, Self-<br />
Assignment is still possible, as an OTP is used as part of the process.<br />
2.5.1 Digipass Lookup<br />
The first step of Local Authentication is to search for Digipass records applicable to the login. Normally, this is a<br />
simple search for all Digipass assigned to the Digipass User account. However, there are exceptions:<br />
2.5.1.1 No Digipass User Account<br />
If there is no Digipass User account, no search will be done. This can occur if Dynamic User Registration is<br />
enabled.<br />
2.5.1.2 Policy Restrictions<br />
The Policy can specify restrictions on which types of Digipass and/or Digipass Applications may be used. Any<br />
combination of the following restrictions can be defined:<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 45
User Authentication Process<br />
Application Names - a list of named Applications. Only Digipass that have one or more of the named<br />
Applications will be usable.<br />
Application Type - either Response Only, Challenge/Response or Multi-Mode. Only Digipass with that<br />
Application Type will be usable, except Multi-Mode will match all application types.<br />
Digipass Type - a list of models such as DPGO3, DP260. Only Digipass from the listed models will be usable.<br />
Therefore, it is possible that a Digipass User account that has a Digipass assigned is not able to use that Digipass<br />
to log in, when a certain Policy applies. They will be regarded as a User without a Digipass in that case. In a<br />
different kind of login, a different Policy may apply, with no restrictions. Then they would be treated as a User with<br />
a Digipass.<br />
For example, a company has Go 3 Digipass (DPGO3) and Primary Virtual Digipass (DPVTL). The Outlook Web<br />
Access login permits both, so its Policy does not restrict Digipass Types. However the RADIUS VPN login requires<br />
the Go 3, so its Policy specifies Digipass Type = DPGO3.<br />
2.5.1.3 Linked User Accounts<br />
If a person has two Digipass User accounts, for example an administrative account and a 'normal user' account,<br />
the two accounts can be linked together. This provides the ability for the two accounts to share a Digipass. The<br />
Digipass is assigned to one of the accounts, then the other account is linked to it.<br />
Digipass record<br />
Attached<br />
to main<br />
User<br />
account<br />
Digipass User<br />
account 1<br />
User can log into<br />
either account<br />
using the same<br />
Digipass<br />
Image 17: User Account Link<br />
User Account Link<br />
Digipass User<br />
account 2<br />
When an authenticating Digipass user account is linked to another, the search for Digipass will be done for the<br />
other account. In the example above, Digipass User account 2 is linked to Digipass User account 1. The Digipass is<br />
assigned to Digipass User account 1. When Digipass User account 1 logs in, the Digipass search is for that<br />
account. When Digipass User account 2 logs in however, the Digipass search is for Digipass User account 1.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 46
2.5.2 Authentication with Digipass<br />
2.5.2.1 <strong>Server</strong> PIN<br />
2.5.2.2 Grace Period<br />
User Authentication Process<br />
When the Digipass lookup returns at least one Digipass record, authentication processing requires a valid One<br />
Time Password to succeed, unless:<br />
All Digipass found are within a Grace Period. This feature is described below.<br />
The User successfully requests a Challenge for Challenge/Response (see below).<br />
The User successfully requests a Virtual Digipass One Time Password (see below).<br />
A <strong>Server</strong> PIN may be required in addition to the One Time Password. The <strong>Server</strong> PIN is entered during login with<br />
the OTP - instead of a Digipass PIN, which is entered into the Digipass device. In some cases a new <strong>Server</strong> PIN<br />
may need to be set. This gives the following permutations:<br />
OTP - the normal login where a <strong>Server</strong> PIN is not required.<br />
PINOTP - the normal login where a <strong>Server</strong> PIN is required.<br />
PINOTPnewpinnewpin - to change the <strong>Server</strong> PIN, the new PIN is put twice after the OTP.<br />
OTPnewpinnewpin - to set the <strong>Server</strong> PIN on first use, when no initial PIN was programmed, the new PIN is put<br />
twice after the OTP. This is also necessary after an administrative PIN reset.<br />
Each Digipass may be given a Grace Period when it is assigned to a Digipass User account. The Grace Period is<br />
there to allow some time before the User receives the Digipass and learns how to use it. The first time that the<br />
User logs in successfully with their Digipass, the Grace Period is ended. After that, they have to continue to use the<br />
Digipass. The Grace Period is time limited, so that the User is not able to delay too long before they start to use the<br />
Digipass.<br />
The Grace Period can be set during manual administrative assignment of Digipass as well as during Auto-<br />
Assignment. However, it is not applicable to Self-Assignment, because the User must use the Digipass to<br />
complete the Self-Assignment process.<br />
The Grace Period cannot apply when the Local Authentication setting is Digipass Only.<br />
During the Grace Period, if OTP validation fails, the static password is checked. If the static password is valid, Local<br />
Authentication succeeds (but note that Back-End Authentication, if used, can subsequently still cause the overall<br />
login to fail).<br />
The password is compared against the Digipass User account's password value. However, if the Digipass User<br />
account does not have a password set, the password has to be verified with Back-End Authentication. If there is no<br />
Back-End Authentication and no password in the Digipass User account, Grace Period password logins will not<br />
work.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 47
User Authentication Process<br />
If the passwords do not match and Back-End Authentication is enabled, the password will be verified with Back-<br />
End Authentication.<br />
2.5.2.3 Challenge Generation<br />
There are two modes of Challenge generation for Challenge/Response:<br />
2-Step Challenge/Response<br />
This mode can be used for Web authentication, where Challenge/Response is supported. In this mode, the<br />
authentication process takes place in two steps.<br />
First, the User requests a Challenge to be generated for them. The Policy defines how this request should be<br />
made, with the Request Method and Request Keyword settings (see below for more details on Request Methods).<br />
The Challenge is generated specifically for their Digipass, according to its programming.<br />
Assuming that the request for the Challenge is accepted and a Challenge is returned, the User submits a second<br />
step login with the Response to the Challenge as their OTP. This second step goes through the whole<br />
authentication process again to verify the Response.<br />
1-Step Challenge/Response<br />
This mode is also possible for Web authentication, where Challenge/Response is supported. In this mode, the User<br />
sees only one logon step. This mode is suitable for time-based Challenge/Response, but is less secure for nontime<br />
based Challenge/Response. If an attacker manages to capture some valid Responses, they can repeatedly<br />
request new Challenges until one they know comes up again.<br />
A random Challenge is requested automatically by the Web Application and presented to the User on the login<br />
page. A general-purpose Challenge is generated, without reference to any particular Digipass' programming. The<br />
User logs in with their Response to the Challenge as their OTP.<br />
2.5.2.4 Virtual Digipass OTP Generation<br />
Using Virtual Digipass, the authentication process takes place in two steps.<br />
First, the User requests an OTP to be generated and delivered to them. The Policy defines how this request should<br />
be made, with the Request Method and Request Keyword settings (see below for more details on Request<br />
Methods). The OTP is generated specifically for their Digipass, according to its programming. It is sent to their<br />
mobile phone number, as recorded in the Digipass User account.<br />
Backup Virtual Digipass has additional restrictions on usage, to keep the cost of text messages down. These are<br />
verified before an OTP will be generated. These restrictions are described in 7 Digipass.<br />
Assuming that the request for the OTP is accepted and an OTP is generated and delivered successfully, the User<br />
submits a second step login with the OTP. This second step goes through the whole authentication process again<br />
to verify the OTP.<br />
This process is illustrated below:<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 48
Image 18: Virtual Digipass Login<br />
2.5.2.5 Requesting a Virtual Digipass OTP - User Perspective<br />
User Authentication Process<br />
There are three ways a User might request a One Time Password to be delivered with either a Primary or Backup<br />
Virtual Digipass:<br />
2-step Login<br />
Two login prompts are used to provide an easy-to-use login interface for Users with Virtual Digipass. The first<br />
prompt is used to request an OTP, the second to enter the received OTP. This can be used with applications which<br />
support 2-step logins eg. Citrix Web Interface, RADIUS with support for Challenge/Response.<br />
Two 1-step Logins<br />
The User must attempt two logins, the first of which will fail but will initiate the sending of an OTP to the User’s<br />
mobile. This is used when the 2-step login process is not supported - eg. RADIUS without support for<br />
Challenge/Response, Web HTTP Basic Authentication.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 49
OTP Request Site<br />
User Authentication Process<br />
Alternatively - especially if a more user-friendly option than the previous is needed - Users can go to the OTP<br />
Request site when they need an OTP sent to their mobile phone, then login normally at the usual login screen.<br />
2.5.2.6 Request Method and Keyword<br />
For 2-Step Challenge/Response and Virtual Digipass, the method of requesting a Challenge or OTP respectively<br />
can be defined in the Policy. The methods for Primary Virtual Digipass and Backup Virtual Digipass are defined<br />
separately. The request methods are:<br />
Password - the static password.<br />
Keyword - a fixed keyword, which can be blank.<br />
PasswordKeyword - the static password followed by a fixed keyword, with no whitespace or separating<br />
characters inbetween.<br />
KeywordPassword - a fixed keyword followed by the static password, with no whitespace or separating<br />
characters inbetween.<br />
None - no method, the feature is disabled.<br />
Note<br />
If Password is set for the Request Method, and a User's Digipass is still within the Grace Period,<br />
<strong>Identikey</strong> <strong>Server</strong> may process the authentication with the password only and not as a 2-Step<br />
Challenge/Response or Virtual Digipass login.<br />
The static password in the request method is compared against the Digipass User account's password value.<br />
However, if the Digipass User account does not have a password set, the password has to be verified with Back-<br />
End Authentication. If there is no Back-End Authentication and no password in the Digipass User account, the<br />
request methods that use a password will not work.<br />
If the passwords do not match and Back-End Authentication is enabled, the password will be verified with Back-<br />
End Authentication.<br />
The methods of requesting these three login processes can be the same. When it recognizes a request, the<br />
<strong>Identikey</strong> <strong>Server</strong> will verify that there is a Digipass capable of that login process. If there is not, it will ignore the<br />
request.<br />
For example, say that the request methods for Primary and Backup Virtual Digipass are both defined as keyword<br />
“otp”. A User has a Go 3 with Backup Virtual Digipass enabled. When they login with the keyword “otp”, the<br />
<strong>Identikey</strong> <strong>Server</strong> will produce a Backup Virtual Digipass OTP, because the User does not have a Primary Virtual<br />
Digipass.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 50
2.5.2.7 Multiple Digipass or Digipass Applications<br />
User Authentication Process<br />
A Digipass User may have multiple Digipass assigned to their User account, and/or multiple Applications enabled<br />
for a Digipass. If so, the <strong>Identikey</strong> <strong>Server</strong> will need to know which Digipass and Digipass Application will be used<br />
for a particular login for the User.<br />
Image 19: Multiple Digipass Assignment<br />
Once the Policy restrictions on Applications and Digipass Types are taken into account, there may still be more<br />
than one Digipass Application that could be used. In that case, the <strong>Identikey</strong> <strong>Server</strong> will check the OTP with each<br />
one. Any one of them can validate the OTP.<br />
A Grace Period may be applied to each Digipass assigned to a Digipass User. Because an applied Policy might<br />
restrict which Digipass can be used during a login, the Grace Period on each Digipass is independent of other<br />
Digipass. This means that if a User is assigned two Digipass, each with a Grace Period of seven days, the User<br />
may log in using one Digipass within the seven-day period (ending the Grace Period for that Digipass) without<br />
affecting the Grace Period for the other Digipass.<br />
Example<br />
The company has set up Policies which require a Response Only login via the local area network, and a Challenge/Response login<br />
via the internet – limited to certain employees.<br />
John has two Digipass assigned to him – a DP300 with the Challenge/Response application enabled, and a Go 3 with a Response<br />
Only application. The Digipass are both assigned on Tuesday.<br />
John receives his Go 3 on Friday, and immediately uses an OTP to login. His grace period for the Go 3 ends at that time – in future<br />
he must use the Go 3 when logging into the intranet from the LAN.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 51
User Authentication Process<br />
Over the weekend, John needs to access the company intranet from home. Because a Challenge/Response login is required via the<br />
internet and he does not yet have his DP300, he uses only his User ID and static password to log in. As he is still within the grace<br />
period for the DP300, the login is valid.<br />
2.5.3 Authentication without Digipass<br />
When the Digipass lookup does not return a Digipass record, authentication processing requires a static password<br />
check to succeed. In addition, Self-Assignment is possible when the Digipass lookup does not return any Digipass.<br />
2.5.3.1 Static Password Verification<br />
2.5.3.2 Self-Assignment<br />
The password is compared against the Digipass User account's password value. If the static password is valid,<br />
Local Authentication succeeds (but note that Back-End Authentication, if used, can subsequently still cause the<br />
overall login to fail).<br />
However, if the Digipass User account does not have a password set, the password has to be verified with Back-<br />
End Authentication. If there is no Back-End Authentication and no password in the Digipass User account,<br />
authentication without Digipass cannot work. Similarly, during Dynamic User Registration, where there is no<br />
Digipass User account yet, the password has to be verified with Back-End Authentication.<br />
If the passwords do not match and Back-End Authentication is enabled, the password will be verified with Back-<br />
End Authentication.<br />
If the Local Authentication setting is Digipass Only, static password verification on its own is not permitted. An<br />
OTP must be used during login. This is possible using Self-Assignment.<br />
A User is able to assign a Digipass to their Digipass User account using the Self-Assignment mechanism, when<br />
permitted by the Policy settings. The Assignment Mode setting must be Self-Assignment.<br />
In order for Self-Assignment to succeed, the User needs to provide the following:<br />
A static password, validated by Back-End Authentication.<br />
The Serial Number of an available Digipass record.<br />
A valid OTP for the Digipass.<br />
A new <strong>Server</strong> PIN, if required.<br />
The Self-Assignment process is possible during Dynamic User Registration. It is also possible when the Local<br />
Authentication setting is Digipass Only.<br />
Response Only<br />
For a Digipass that supports Response Only, the User needs to enter the following in the password login field,<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 52
depending on whether a <strong>Server</strong> PIN is needed or not:<br />
SERIALNUMBERpasswordOTP – where a <strong>Server</strong> PIN is not required.<br />
SERIALNUMBERpasswordPINOTP – where a <strong>Server</strong> PIN is required.<br />
User Authentication Process<br />
SERIALNUMBERpasswordOTPnewpinnewpin – where a <strong>Server</strong> PIN is required and no initial PIN was set.<br />
Challenge/Response<br />
For a Digipass that supports only Challenge/Response, this process requires two steps. In the first step, the static<br />
password and Serial Number are given. This results in a Challenge being returned. If the correct Response is given<br />
to the Challenge, the Self-Assignment is successful.<br />
Step 1: SERIALNUMBERpassword<br />
Step 2: OTP<br />
Serial Number Format<br />
The SERIALNUMBER may be entered in one of two formats, depending on the Serial No. Separator Policy setting.<br />
No separator specified – the full 10 digit Serial Number must be entered, with no dashes (-) or spaces, for<br />
example 0097123456.<br />
Separator value specified – the Serial Number can be entered as written on the back of the Digipass, for<br />
example 9-712345-6.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 53
2.6 Back-End Authentication<br />
User Authentication Process<br />
Back-End Authentication is a term used to describe the process of checking User credentials with another<br />
system. It is used primarily for:<br />
Enabling automatic management features such as Dynamic User Registration and Self-Assignment<br />
Static password verification for Users who do not have a Digipass and for Virtual Digipass<br />
Retrieval of RADIUS attributes from a RADIUS server<br />
Password Replacement - allowing the User to log in with just a One Time Password, in an environment where<br />
the Windows password is required (eg. Outlook Web Access)<br />
<strong>Identikey</strong> <strong>Server</strong> supports Back-End Authentication with the following systems:<br />
Windows<br />
Microsoft Active Directory<br />
Microsoft ADAM<br />
Novell e-Directory<br />
RADIUS<br />
Custom solution (requires SDK)<br />
An <strong>Identikey</strong> <strong>Server</strong> can authenticate Windows Users via Windows or LDAP Active Directory Back-End<br />
Authentication. Windows Back-End Authentication should be used where the <strong>Identikey</strong> <strong>Server</strong> is installed on a<br />
Windows machine which is a member server of the Windows domain. LDAP Back-End Authentication may be used<br />
where the machine on which it is installed is either not a member server of the Windows domain, or running a<br />
Linux operating system.<br />
The Back-End Authentication Policy setting indicates whether to perform Back-End Authentication, and if so,<br />
when to do it. This setting is overridden by the same setting in the Digipass User account, unless that has the value<br />
Default. However, this setting in the Digipass User account would typically be used only for rare special case Users.<br />
Using the Windows Group Check in Back-End Mode, this setting can be overridden. If a User is not in the list of<br />
groups, Back-End Authentication will be performed whether it is enabled or not.<br />
The Back-End Protocol setting indicates which type of Back-End Authentication is to be used.<br />
The possible values for the Back-End Authentication setting are as follows:<br />
None<br />
The <strong>Identikey</strong> <strong>Server</strong> will not utilize Back-End Authentication.<br />
Always<br />
The <strong>Identikey</strong> <strong>Server</strong> will use Back-End Authentication for every authentication request. This is necessary if you<br />
require RADIUS attributes for each login.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 54
If Needed<br />
User Authentication Process<br />
Back-End Authentication will only be used in situations where Local Authentication is not sufficient and to support<br />
certain features:<br />
Dynamic User Registration<br />
Self-Assignment<br />
Password Autolearn (see below)<br />
Requesting a Challenge or Virtual Digipass OTP, when the Request Method includes a Password<br />
Static password authentication, when verifying a Virtual Digipass password-OTP combination or during the<br />
Grace Period<br />
2.6.2 Stored Static Password<br />
The Digipass User account has a Stored Static Password field. When Back-End Authentication is used, this field<br />
can be used:<br />
To store the static password required for Back-End Authentication. This means that the User does not need to<br />
type in the static password at each login, they only need enter the OTP. The <strong>Identikey</strong> <strong>Server</strong> can retrieve the<br />
Stored Static Password from the Digipass User account and use it for Back-End Authentication.<br />
To support Password Replacement. Back-End Authentication is used to learn the static password so that it can<br />
be replayed to the host system (eg. Outlook Web Access) when a successful OTP is given.<br />
Two product features are used to support this usage of the Stored Static Password: Stored Password Proxy and<br />
Password Autolearn.<br />
2.6.3 Stored Password Proxy<br />
When the Stored Password Proxy setting is enabled in the Policy, the <strong>Identikey</strong> <strong>Server</strong> will retrieve the Stored<br />
Static Password from the Digipass User account. If Back-End Authentication is required for a login, the Stored<br />
Static Password will be used. If there is a host system (eg. Outlook Web Access), the Stored Static Password will<br />
be returned to it, for it to complete its login process.<br />
However, if the User enters a static password in front of their OTP, the static password they enter will take<br />
precedence over Stored Static Password. In that case, the Stored Static Password will not be used at all for that<br />
login.<br />
When the Stored Password Proxy setting is not enabled in the Policy, the Stored Static Password will not be used<br />
for Back-End Authentication. If Back-End Authentication is required for a login, the User will have to enter the static<br />
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<br />
static password to be returned, the User will have to enter the static password.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 55
2.6.4 Password Autolearn<br />
User Authentication Process<br />
When the Password Autolearn feature is enabled in the Policy, the <strong>Identikey</strong> <strong>Server</strong> will automatically store the<br />
static password when it is verified by Back-End Authentication. This can happen at any time from Dynamic User<br />
Registration onwards.<br />
If the User's static password has changed in the Back-End Authentication system, they will need to provide the new<br />
static password during their next login. This is done in front of the OTP if an OTP is used. When the <strong>Identikey</strong><br />
<strong>Server</strong> sees that the User has entered a static password, if it does not match the Stored Static Password already,<br />
Back-End Authentication will occur to verify the new password. If it is verified, the Stored Static Password will be<br />
updated.<br />
2.6.5 Back-End <strong>Server</strong> Records<br />
A Back-End <strong>Server</strong> record is required for RADIUS and LDAP-based Back-End authentications. It contains<br />
connection information for the system to be used. Typically, only one Back-End <strong>Server</strong> record will be required for<br />
LDAP Back-End Authentication, whereas RADIUS Back-End Authentication will require a record per RADIUS <strong>Server</strong><br />
to be used.<br />
2.6.5.1 Fail-over Strategy<br />
Each Back-End <strong>Server</strong> record is assigned a Priority. This comes into effect when multiple Back-End <strong>Server</strong>s are<br />
available, and the <strong>Identikey</strong> <strong>Server</strong> must decide which to use for a Back-End Authentication request. It will attempt<br />
to connect to the Back-End <strong>Server</strong> with the highest Priority rating. If it is not available after the set No. of Retries,<br />
the <strong>Identikey</strong> <strong>Server</strong> will attempt to connect to the Back-End <strong>Server</strong> with the next-highest Priority rating.<br />
If the <strong>Identikey</strong> <strong>Server</strong> repeatedly fails to get a response from a Back-End <strong>Server</strong>, it will ignore it for some minutes<br />
before trying it again. Therefore, a temporary slow response will not prevent the <strong>Identikey</strong> <strong>Server</strong> from using a<br />
Back-End <strong>Server</strong>. But a consistent availability problem will cause it to stop using the Back-End <strong>Server</strong> for a while,<br />
when it has an alternative.<br />
2.6.5.2 Domain-Specific Back-End <strong>Server</strong>s<br />
Back-End <strong>Server</strong> records may be configured for use with a specific Domain. This may be useful when multiple<br />
Back-End servers exist with different groups of User records on each.<br />
When the <strong>Identikey</strong> <strong>Server</strong> has to choose a Back-End <strong>Server</strong>, it will search for those records in the Domain<br />
identified by the User ID and Name Resolution process. If any are found, it will only use those Back-End <strong>Server</strong>s<br />
for that Domain. If none are found, it will use the Back-End <strong>Server</strong>s that are not assigned to a Domain.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 56
2.6.6 RADIUS Back-End Authentication<br />
User Authentication Process<br />
<strong>Identikey</strong> <strong>Server</strong> can pass RADIUS return attributes from the Back-End server to the client. Back-End Authentication<br />
is supported with the following protocols:<br />
PAP<br />
CHAP<br />
MS-CHAP<br />
MS-CHAP2 with MPPE key generation<br />
Note<br />
<strong>Identikey</strong> <strong>Server</strong> does not provide stand-alone RADIUS attribute support.<br />
2.6.7 Microsoft Active Directory Back-End Authentication using LDAP protocol<br />
Note<br />
For instructions on setting up a Back-End <strong>Server</strong> record for an Active Directory server, see the<br />
Administration Web Interface online help.<br />
When using Microsoft Active Directory with <strong>Identikey</strong> <strong>Server</strong> for Back-End Authentication:<br />
The Domain Controllers must be Windows <strong>Server</strong> 2003 or higher.<br />
Microsoft Windows 2000 is not supported<br />
If the global catalog is set up (via Administration Web Interface -> Back End -> Settings) and no back-end<br />
components have been defined, domain discovery via the global catalog will be used to search for the User. If<br />
domain discovery via the global catalog is to be used, Users must be set up in the same Domain on Active<br />
Directory as they are on <strong>Identikey</strong> <strong>Server</strong><br />
The <strong>Identikey</strong> <strong>Server</strong> must be configured to use the DNS server containing the DNS records of the Active<br />
Directory server or an entry has to be present in the host file that maps the IP of the Active Directory domain<br />
controller to the fully qualified domain name of the domain controller. On Linux this has to be configured on<br />
both the host OS and chroot level.<br />
Note<br />
The Active Directory back end may be configured to authenticate Active Directory users via an<br />
instance of ADAM that has been installed on the domain controller, with the condition that the<br />
user's <strong>Identikey</strong> <strong>Server</strong> domain and Active Directory domain have the same name. The ADAM<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 57
instance will automatically delegate authentication to Active Directory<br />
The steps in Back-End Authentication for Active Directory are:<br />
User Authentication Process<br />
1. Identify the Active Directory Domain Controller using the LDAP Back End <strong>Server</strong> entries in the data store or<br />
the Global Catalog.<br />
Supported User Logon Format for Microsoft Active Directory-<br />
Userid Format Source of Userid<br />
UserID SAMAccountName attribute of the user<br />
MYREALM\userid Fully qualified domain name + SAMAccountName attribute of the user<br />
userid@mydomain.com SamAccountName attribute of the user + fully qualified domain name<br />
2. <strong>Identikey</strong> <strong>Server</strong> will bind to the directory server that handles the authentication request it will use the UserID<br />
and the password specified in the authentication request received by the <strong>Identikey</strong> <strong>Server</strong>. If the bind<br />
succeeds, the user authentication is deemed to be successful. If the bind fails, the authentication is deemed<br />
to have failed.<br />
Note<br />
<strong>Identikey</strong> <strong>Server</strong> only supports SASL.Digest-MD5 binding as the client authentication mechanism<br />
for binding with the supported Back-End authentication servers.<br />
2.6.8 Novell e-Directory Back End Authentication using LDAP protocol<br />
Note<br />
For instructions on setting up a Back-End <strong>Server</strong> record for an e-Directory server, see the<br />
Administration Web Interface online help.<br />
The version of Novell e-Directory used for LDAP Back-End Authentication on <strong>Identikey</strong> <strong>Server</strong> must be version 8.7<br />
or higher.<br />
The following rules must be followed to set up Novell e-Directory for LDAP Back-End Authentication on <strong>Identikey</strong><br />
<strong>Server</strong>:<br />
If anonymous binding is disabled on the eDirectory server the Security Principal DN has to be an eDirectory<br />
account that has the necessary permissions to search the directory for the user accounts that have to be<br />
authenticated.<br />
Each userid has to be unique below the search Base Distinguished name in the LDAP structure.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 58
User Authentication Process<br />
Partitioning is not supported, although exactly the same search Base Distinguished name may be used on<br />
different servers.<br />
Novell e-Directory must be enabled with Universal Password.<br />
Supported User Logon Format for Novell e-Directory-<br />
Userid Format Source of Userid<br />
UserID Userid of the user<br />
MYREALM\userid Fully qualified domain name + Userid of the user<br />
userid@mydomain.com Userid attribute of the user + fully qualified domain name<br />
The steps in Back-End Authentication for Novell eDirectory are:<br />
1. Identify the eDirectory server based on the eDirectory Back-End entries in <strong>Identikey</strong> <strong>Server</strong>.<br />
2. Bind to eDirectory using the security principal DN and password defined for the eDirectory back-end if<br />
principal details specified.<br />
3. Search eDirectory for the FQDN of the user that has to be authenticated (starting from the Base Search DN).<br />
4. Try to authenthicate with eDirectory using a bind with the FQDN and password of the user to be<br />
authenticated<br />
Note<br />
<strong>Identikey</strong> <strong>Server</strong> only supports SASL.Digest-MD5 binding as the client authentication mechanism<br />
for binding with the supported Back-End authentication servers.<br />
Image 20: The steps in Back-End Authentication for Novell eDirectory and ADAM<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 59
2.6.9 ADAM Back End Authentication using LDAP protocol<br />
Note<br />
User Authentication Process<br />
For instructions on setting up a Back-End <strong>Server</strong> record for an ADAM server, see the<br />
Administration Web Interface online help.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 60
User Authentication Process<br />
The following rules must be followed to set up ADAM for LDAP Back-End Authentication on <strong>Identikey</strong> <strong>Server</strong>:<br />
If anonymous binding is disabled the security Principal DN has to be an ADAM account that belongs to the<br />
READERS role<br />
Note<br />
ADAM back end authentication is not available for users in an instance of ADAM that has been<br />
installed on a Domain Controller or on a machine that is a member of the domain.<br />
Supported User Logon Format for ADAM-<br />
Userid Format Source of Userid<br />
UserID Common name of the user<br />
MYREALM\userid Fully qualified domain name + common name of the user<br />
userid@mydomain.com Common name attribute of the user + fully qualified domain name<br />
The steps in Back-End Authentication for ADAM are:<br />
1. Identify the ADAM server based on the ADAM Back-End entries in <strong>Identikey</strong> <strong>Server</strong>.<br />
2. Bind to ADAM using the security principal DN and password defined for the ADAM back-end if principal<br />
details specified.<br />
3. Search ADAM for the FQDN of the user that has to be authenticated (starting from the Base Search DN).<br />
4. Try to authenthicate with ADAM using a bind with the FQDN and password of the user to be authenticated<br />
Note<br />
<strong>Identikey</strong> <strong>Server</strong> only supports SASL.Digest-MD5 binding as the client authentication mechanism<br />
for binding with the supported Back-End authentication servers.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 61
2.7 Authorization Profiles/Attributes<br />
User Authentication Process<br />
A Web Application using SOAP may retrieve authorization data from Digipass User Accounts. For example, a<br />
lookup key in the web application's database.<br />
Some IIS Modules utilise User attributes to allow a web site to retrieve authorization information from local<br />
Windows accounts.<br />
Individual User attributes may be set for a Digipass User account. The <strong>Identikey</strong> <strong>Server</strong> will return these attributes<br />
to the Web Application during authentication if requested.<br />
2.7.1 User Attribute Settings<br />
Attribute Group<br />
An Attribute Group is specified by the Web Application as a parameter to the authorization request. When multiple<br />
IIS Modules are in use, the specified Attribute Group ensures that only attributes required by the specific Web<br />
Application are used.<br />
Name<br />
A name for the attribute as expected by the Web Application.<br />
Usage<br />
Value<br />
Basic indicates that the attribute is for use by the IIS 6 Module for Basic Authentication.<br />
Other options are available for Digipass Plug-In for SBR and are not relevant for <strong>Identikey</strong> <strong>Server</strong>.<br />
The Value set for an attribute will be the required value of the named attribute.<br />
2.8 Host Code Generation<br />
If the Web Application requests a Host Code and the Digipass is capable of generating one then <strong>Identikey</strong> <strong>Server</strong><br />
will generate a Host Code and the application will display it to the User. The User generates a Host Code on their<br />
Digipass and checks that it is the same as the one on the screen.<br />
Host Code generation is passed as a parameter in the authentication request. There are two options:<br />
Optional - only return a Host Code if the Digipass is Host Code capable<br />
Required - Digipass must be Host Code capable or the request will fail.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 62
2.9 Supported RADIUS Password Protocols<br />
The following protocols are supported by <strong>Identikey</strong> <strong>Server</strong>:<br />
PAP<br />
CHAP<br />
MS-CHAP with MPPE (Microsoft Point-to-Point Encryption)<br />
MS-CHAP2 with MPPE<br />
User Authentication Process<br />
Some protocols do not support all authentication features of <strong>Identikey</strong> <strong>Server</strong>. See 2.10 Unsupported by <strong>Identikey</strong><br />
<strong>Server</strong> and the Login Permutations section of the Administrator Reference for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 63
2.10 Unsupported by <strong>Identikey</strong> <strong>Server</strong><br />
2.10.1 Limitations of RADIUS Password Protocols<br />
User Authentication Process<br />
Some features of the <strong>Identikey</strong> <strong>Server</strong> are not supported with CHAP or MS-CHAP. These protocols hash login data<br />
together, making separation of various entries impossible.<br />
The unsupported features are outlined below:<br />
Self-Assignment of Digipass cannot be performed.<br />
The <strong>Server</strong> PIN cannot be changed.<br />
Challenge/Response is not supported.<br />
Windows Back-End Authentication is not supported unless the User ID and Windows password are manually<br />
stored, and Stored Password Proxy is enabled.<br />
Password Autolearn is not supported, as clear text passwords cannot be identified.<br />
The User Self-Management Web Site, when utilized, can circumvent many of these problems by allowing Users to<br />
manage their account and Digipass. It uses RADIUS with the PAP password protocol. Users can:<br />
Perform Self-Assignment<br />
Change their <strong>Server</strong> PIN<br />
Change their own Stored Static Password<br />
2.10.2 Unsupported RADIUS Password Protocols<br />
MS-CHAP with LM Hash<br />
The password change mechanism for MS-CHAP and MS-CHAP2<br />
EAP<br />
2.10.3 Limitations of International Character Support<br />
A number of <strong>Identikey</strong> <strong>Server</strong> components provide international character support, and some limitations apply:<br />
Database<br />
International character support in the database is dependent on the individual database driver. See the Encoding<br />
and Case Sensitivity topic in the Administrator Reference for more information.<br />
RADIUS<br />
International character support in the <strong>Identikey</strong> <strong>Server</strong> using the RADIUS protocol is dependent on the RADIUS<br />
Client(s) being used. If a RADIUS Client uses UTF-8 encoding, international characters will be fully supported. If a<br />
RADIUS Client uses a localized encoding (eg. ISO-8859-13), the same locale setting must be configured on each<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 64
machine.<br />
Web<br />
User Authentication Process<br />
For the Digipass Pack for OWA Basic Authentication and the Digipass Pack for OWA Forms Authentication,<br />
international character support is limited to a single configured encoding. See the <strong>Guide</strong> for the specific Digipass<br />
Pack for more information.<br />
DPADMINCMD<br />
DPADMINCMD supports international characters, but your console window must be able to support the characters<br />
or they will not display correctly.<br />
2.10.4 Limitations of Web Basic Authentication<br />
Some features of the <strong>Identikey</strong> <strong>Server</strong> are not supported with the HTTP Basic Authentication mechanism. This<br />
mechanism does not support a 2-step login process.<br />
The unsupported features are outlined below:<br />
Challenge/Response is not supported.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 65
3 Signature Validation Process<br />
3.1 Signing a Transaction<br />
Signature Validation Process<br />
<strong>Identikey</strong> <strong>Server</strong> will allow you to sign transaction data using a Digipass that is set up to generate digital signatures.<br />
A digital signature is based on transaction details entered into the Digipass. The Digipass uses the transaction<br />
details and an embedded secret to generate a signature, which is typically entered into a confirmation page to<br />
proceed with the transaction. This signature will be validated by the server – if it is incorrect the transaction will<br />
not be permitted to proceed.<br />
3.2 How Do I Generate a Signature?<br />
Signature generation will be an application on your Digipass.<br />
1. Select the Signature application on your Digipass.<br />
2. Enter the required transaction details. Digipass can be programmed to accept up to eight transaction data<br />
fields such as:<br />
transaction amount<br />
transaction ID<br />
destination account number<br />
3. The Digipass will generate a signature and display it on its screen. Enter the generated signature into the<br />
transaction you are signing and submit the transaction.<br />
3.2.1 Real Time Signature Validation<br />
Real Time Signature Validation is signature validation that is performed in real-time, such as through an online<br />
banking application.<br />
A typical scenario is where a User creates a transaction, say, paying a bill on a banking website. The transaction<br />
requires a signature so the User enters the relevant details into their Digipass. The Digipass produces a signature<br />
and the User enters this into the website and then submits the transaction. The transaction details and signature<br />
are verified by <strong>Identikey</strong> <strong>Server</strong> and a status message is returned straight to the web page the User is on. The<br />
User knows within the time it takes to process a normal transaction whether or not the transaction they submitted<br />
has been verified.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 66
3.2.2 Deferred Signature Validation<br />
Signature Validation Process<br />
Deferred time Signature Validation is signature validation that is not performed in real time. An example scenario<br />
may be that a User submits a transaction online with the signature generated by the Digipass. The transaction will<br />
then enter a queue to be verified. The User receives a message that the transaction has gone into a queue. A<br />
batch job picks up the transaction and verifies it against the policies and details of the Digipass. The User may not<br />
know until minutes or hours later that the transaction has been signed and verified. It is important in this case for<br />
the User to keep a record of the time the transaction was submitted, as this may be important if the transaction is<br />
challenged.<br />
3.3 Time based signature<br />
The signature application may be time based. This means that the Digipass will generate a different signature for<br />
the same input data at different times.<br />
The signature validation procedure relies on the time on the Digipass and the time on <strong>Identikey</strong> <strong>Server</strong> being<br />
synchronized to within an acceptable tolerance. Each time a One Time Password or a signature is generated the<br />
<strong>Identikey</strong> <strong>Server</strong> records the difference in times between the Digipass and itself. The time based signature<br />
validation procedure also uses Time Steps to verify signatures. A Time Step is a setting which specifies the<br />
number of seconds between generations of a One Time Password on a Digipass. The <strong>Identikey</strong> <strong>Server</strong> will use the<br />
time step and the known difference in time between itself and the Digipass to verify signatures.<br />
Use the STimeWindow policy setting to set the tolerance allowable for signature verification.<br />
Time based signatures can be real-time or deferred. If deferred time based signatures are used they may be reverified<br />
at a later date by comparing the input details against the signature produced by the Digipass, as long as<br />
the time the transaction was performed is known.<br />
3.4 Event Based Signature<br />
The signature application may be event based. This means that it contains a numeric counter that increases every<br />
time a signature is generated.<br />
The signature process relies on an event counter to enable each signature to be unique. The Digipass and<br />
<strong>Identikey</strong> <strong>Server</strong> need to have synchronized event counters. The tolerance for the difference between the event<br />
counters can be set by using the Event Windows policy setting.<br />
During Real Time Signature Validation the event counter on <strong>Identikey</strong> <strong>Server</strong> is updated with the value used by the<br />
Digipass, to keep the two event counter values synchronized.<br />
During Deferred Time Signature Validation the event counters for transactions generated on the Digipass may get<br />
out of step with the event counter held on <strong>Identikey</strong> <strong>Server</strong>. Setting the Event Window policy setting will enable<br />
signed transactions to be processed in any order without causing a verification error.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 67
3.5 Static Signature<br />
Signature Validation Process<br />
These signatures are generated using neither time or event counter. They will always produce the same signature<br />
for the same input. There is no difference between real-time and deferred time with these signatures.<br />
3.6 Signature Verification Process<br />
Digital Signatures are verified by <strong>Identikey</strong> <strong>Server</strong> using a number of specific checks.<br />
Image 21: Steps of Signature Verification Process<br />
3.6.1 Component Checks<br />
<strong>Identikey</strong> <strong>Server</strong> will try to identify the application from which the request for registration came. There must be a<br />
component record on the data store for that application. A client component record must exist for the Signature<br />
Verification application and location from which it connects to the server. The component type is set as a<br />
parameter by the application; the location is the source IP address of the SOAP address.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 68
3.6.2 Policy Checks<br />
Signature Validation Process<br />
<strong>Identikey</strong> <strong>Server</strong> identifies the policy to use in the signature authentication from the client component record and<br />
checks the validity of the policy.<br />
3.6.3 User Account Lookup and Checks<br />
<strong>Identikey</strong> <strong>Server</strong> checks the User Account to :<br />
Ensure that the User ID and Domain have been defined<br />
Perform the Windows Group Check if necessary<br />
Check whether a User Account exists<br />
Check whether the User account is disabled or locked if it already exists.<br />
Dynamic User Registration is NOT possible. If the User Account does not exist then the check will fail.<br />
3.6.4 Signature Validation<br />
3.6.5 Finalization<br />
A search is performed for a Digipass that is assigned to the User that fulfils the Signature policy limits. If more<br />
than one Digipass is found the list is filtered by using the Serial Number for the Digipass, which will have to be<br />
passed into the signature process as a parameter. Allowance should be made when designing the web page that<br />
will allow transactions to be signed, to make sure that Users with more than one Digipass can enter a Serial<br />
Number to identify which one is being used.<br />
When the correct Digipass is identified the Digipass type is checked. The Digipass type must be either 'SG'<br />
(Signature) or 'MM' (Multi Mode) to allow signatures. The signature is then verified and a response is produced.<br />
The relevant parts of the Data Store are updated after the signature validation has been carried out successfully. A<br />
response is produced. The Audit data is updated with the transactions that took place and the result of those<br />
transactions.<br />
If the Web Application requests a Confirmation Code and the Digipass is capable of generating one then <strong>Identikey</strong><br />
<strong>Server</strong> will generate a Confirmation Code and the application will display it to the User. The User generates a<br />
Confirmation Code on their Digipass and checks that it is the same as the one on the screen.<br />
Confirmation Code generation is passed as a parameter in the authentication request. There are two options:<br />
Optional - only return a Confirmation Code if the Digipass is Confirmation Code capable<br />
Required - Digipass must be Confirmation Code capable or the request will fail.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 69
3.7 Policy Settings<br />
Signature Validation Process<br />
There are specific Policy settings for signature verification. See the Policy Properties topic in the Field Listings<br />
section of the Administration Reference for information on these settings.<br />
Event Window - the allowable difference between the Digipass event counter and <strong>Identikey</strong> <strong>Server</strong> event<br />
counter.<br />
OnlineSG – specifies how signatures will be verified.<br />
STimeWindow - Shows the acceptable difference in time between the time set on the Digipass and the time<br />
set on <strong>Identikey</strong> <strong>Server</strong> for signatures. The lowest value is 2, the highest is 500.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 70
4 Software Digipass Provisioning<br />
4.1 Software Digipass Provisioning Overview<br />
4.1.1 What is a Software Digipass?<br />
Software Digipass Provisioning<br />
Software Digipass are software versions of Digipass that provide authentication and signature functions for Javaenabled<br />
mobile devices and web browsers. They generate a One Time Password or Digital Signature for you in the<br />
same way as a hardware Digipass. See 1.3 Types of Digipass for more information.<br />
Each Software Digipass requires:<br />
Software installed on the client device<br />
An applet for Digipass for Mobile<br />
An applet for Digipass for Web<br />
An applet for DP110<br />
A unique activation code<br />
Each Software Digipass will have to be installed on the host device, then activated using an activation code. It can<br />
then be used to generate One Time Passwords and Digital Signatures.<br />
4.1.2 Software Digipass Types<br />
The following types are supported by the Provisioning function in <strong>Identikey</strong> <strong>Server</strong>:<br />
Digipass for Mobile<br />
The Digipass for Mobile is a Java applet that runs on any Java enabled mobile phone or BlackBerry. You can use it<br />
to generate a One Time Password or Digital Signature on demand.<br />
Digipass for Web<br />
The Digipass for Web is a Java applet that runs on your internet browser using cookies for data storage. You<br />
must therefore have cookies enabled on your internet browser. Digipass for Web will also generate a One Time<br />
Password or Digital Signature on demand.<br />
DP110<br />
The DP110 is a hybrid Digipass. This means that there is a hardware component, and a software component. A<br />
Java applet runs on your internet browser, and a USB stick is plugged in to the same machine. These two<br />
components together will generate a One Time Password on demand.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 71
4.1.3 What is Provisioning?<br />
Software Digipass Provisioning<br />
The term 'Provisioning' in <strong>Identikey</strong> <strong>Server</strong> refers to delivery, registration, and activation of the software. The three<br />
steps of provisioning are:<br />
1. Software Delivery<br />
You are free to deliver the software in any way you choose. You can either deliver software to Users, or allow<br />
them to download the software from a secure site.<br />
The code required for activation of the Software Digipass or DP110 - the Activation Code - may be delivered<br />
'online' to the Software Digipass application or DP110 that requires it, or it may be delivered 'offline'<br />
Online delivery<br />
Online delivery means that the Activation Code is delivered directly to the application that is going to use it. If the<br />
Activation Code is delivered in this way the User will never see it. This option is available for Digipass for Web,<br />
DP110, and Digipass for Mobile 2.5.<br />
Offline Delivery<br />
Offline delivery means delivering the Activation Code using a mechanism such as email, text message or fax.<br />
In Digipass for Web the Activation Code will typically be delivered in an email containing a link. The applet reads<br />
the Activation Code from the link.<br />
2. User/Digipass Registration<br />
The Digipass records must be imported from a DPX file before Registration can occur.<br />
Each Software Digipass User requires a Digipass User account on <strong>Identikey</strong> <strong>Server</strong>. The User accounts can either<br />
be imported into <strong>Identikey</strong> <strong>Server</strong>, created individually, or created dynamically during registration if Dynamic User<br />
Registration is available.<br />
For Software Digipass to work, a Digipass record needs to be allocated to the User account. This can be done in<br />
two ways:<br />
a. Manually by an Administrator using, for example, the Web Administration interface.<br />
b. Automatically. This is where the Digipass is assigned to the User account during the Registration<br />
process. This will allocate the first Digipass of the correct type and functional ability that it can to the<br />
User. In <strong>Identikey</strong> <strong>Server</strong> this functionality is known as Auto Assignment. See the Digipass chapter in<br />
the <strong>Product</strong> <strong>Guide</strong> for more details.<br />
The second step of Registration is to generate an activation code and send it to the User.<br />
3. Activate Software<br />
Each Software Digipass needs to be activated before it can be used. This means that <strong>Identikey</strong> <strong>Server</strong> is informed<br />
that all the components are in place for the Software Digipass and you are ready to use it.<br />
There are two stages to activation:<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 72
a. Delivering the Activation Code to the software<br />
b. Sending the first One Time Password to the server.<br />
Image 22: Steps of Provisioning<br />
4.1.4 Which <strong>Server</strong> Components implement Provisioning?<br />
Software Digipass Provisioning<br />
There are two main components and one optional component required to implement Provisioning:<br />
Web Application - Customer written.<br />
The Web Application controls the user interaction during Provisioning. The Web Application uses the SOAP SDK to<br />
communicate with <strong>Identikey</strong> <strong>Server</strong>. Refer to the SOAP SDK documentation for more information.<br />
The Web Application:<br />
Can make the Software Digipass software available for download<br />
Has to arrange delivery of the Activation Code to the User<br />
Sends the first One Time Password to <strong>Identikey</strong> <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong> handles Digipass User accounts and Digipass records. It generates Activation Codes, verifies One<br />
Time Passwords and stores static passwords.<br />
Back-End System<br />
The Back-End System can be used by <strong>Identikey</strong> <strong>Server</strong> for Dynamic User Registration and/or static password<br />
verification. See 2.6 Back-End Authentication for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 73
4.2 Provisioning Scenarios<br />
Software Digipass Provisioning<br />
The following scenarios show how Provisioning will work for different Digipass in different situations. Refer to the<br />
table below for the scenario that best fits your requirements:<br />
Scenarios User account<br />
on <strong>Identikey</strong><br />
<strong>Server</strong><br />
Digipass for<br />
Mobile 1<br />
Digipass for<br />
Web 1<br />
Digipass for<br />
Web 2<br />
Digpass for<br />
Web 3<br />
User knows<br />
Static<br />
Password<br />
Local Auth Back-End<br />
Auth<br />
Provisioning Policy<br />
Digipass<br />
Type<br />
Back-End<br />
Protocol<br />
Y Y None None MOB25 - -<br />
Y Y None None WEB10 - -<br />
Y Y Digipass Only or<br />
Digipass/<br />
Password<br />
N Y Digipass Only or<br />
Digipass/<br />
Password<br />
None WEB10 - -<br />
Always or If<br />
Needed<br />
WEB10 Windows,<br />
RADIUS,<br />
LDAP,<br />
custom<br />
DP110 1 Y Y None DP110 - -<br />
DP110 2 N Y None Always DP110 Windows,<br />
RADIUS,<br />
LDAP,<br />
custom<br />
4.2.1 Digipass for Mobile<br />
Scenario 1 - Activation codes are encrypted with pre-loaded static password<br />
Pre-Conditions<br />
The User account has been created on <strong>Identikey</strong> <strong>Server</strong><br />
The User knows their static password<br />
The static password has been imported into <strong>Identikey</strong> <strong>Server</strong><br />
The provisioning policy has been defined with the following settings<br />
No Local Authentication (Digipass/Password)<br />
No Back-End Authentication (None)<br />
Digipass type 'MOB25'<br />
Dynamic<br />
User<br />
Registration<br />
Enabled<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 74<br />
-
Image 23: Digipass for Mobile Scenario 1 process<br />
Procedure<br />
Software Digipass Provisioning<br />
The User enters their mobile number and their mobile type (Java or BlackBerry) into the Provisioning website. The<br />
Provisioning webserver sends an Text Message to the mobile number which contains the URL to be used to<br />
download the DP4Moble applet. The User uses the URL to download the Digipass for Mobile applet, and then<br />
installs the applet on their mobile phone. The User enters their User ID into the applet, and the applet sends a<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 75
Software Digipass Provisioning<br />
registration request to the webserver, which sends a registration request to <strong>Identikey</strong> <strong>Server</strong>. <strong>Identikey</strong> <strong>Server</strong><br />
assigns the Digipass for Mobile Digipass to the user, generates an encrypted activation code and sends it to the<br />
Digipass for Mobile applet.<br />
When the User has the serial number and activation code the second part of the activation can take place. The<br />
User enters their static password into the Software Digipass to activate it. The One Time Password is then<br />
generated and submitted to the Provisioning <strong>Server</strong> and from this server to <strong>Identikey</strong> <strong>Server</strong> to complete the<br />
activation procedure.<br />
A response will be received on the mobile phone indicating whether the activation has been successful.<br />
4.2.2 Digipass for Web<br />
There are three scenarios that can be employed when activating Digipass for Web. They all have different preconditions.<br />
Which scenario is employed will depend on how <strong>Identikey</strong> <strong>Server</strong> is implemented.<br />
Scenario 1 – Activation codes are encrypted with pre-loaded static passwords<br />
Pre-conditions.<br />
User account has been created on <strong>Identikey</strong> <strong>Server</strong><br />
The User knows their static password<br />
The static password has been imported into <strong>Identikey</strong> <strong>Server</strong><br />
Provisioning policy defined with the following settings:<br />
No Local Authentication (None)<br />
No Back-end Authentication (None)<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 76
Process<br />
Image 24: Digipass for Web Scenario 1 Process<br />
Procedure<br />
Software Digipass Provisioning<br />
The User enters their user ID, email address and PIN on the website. If registration is successful the Digipass for<br />
Web applet is provided with the serial number of the Digipass that is to be activated and an encrypted activation<br />
code. Note that the PIN is not sent to the server but is used locally by the Digipass for Web applet.<br />
The User will have to re-enter their User ID, PIN and password to decrypt the Activation Code and complete<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 77
Software Digipass Provisioning<br />
activation. The applet decrypts the Activation Code, activates itself and sends a One Time Password to the server.<br />
A response will be received indicating whether the activation has been successful.<br />
Options<br />
To make sure that the User changes their static password, extra fields can be added to the second page in this<br />
scenario. Fields can be added to the input page so that the User can enter a new static password, and then enter<br />
it again for confirmation. The User needs to do this so that the original password can only be used once, for<br />
activation. The new password can be used for re-activation. See Reactivation section below.<br />
Scenario 2 – Pre-Loaded User Accounts and Static Passwords<br />
Pre-conditions.<br />
the User account has been created on <strong>Identikey</strong> <strong>Server</strong><br />
the User knows their static password<br />
The static password has been imported into <strong>Identikey</strong> <strong>Server</strong><br />
The provisioning policy has been defined with the following settings:<br />
Process<br />
Local Authentication (Digipass Only or Digipass/Password)<br />
No Authentication (None)<br />
Image 25: Digipass for Web Scenario 2 Process<br />
Procedure<br />
The User enters their user ID, email address, static password and PIN on the registration website. If registration is<br />
successful the serial number of the Digipass that is to be activated and an activation code are delivered to the<br />
Digipass for Web applet.<br />
The User re-enters the User ID and PIN. Digipass for Web generates a One Time Password and then submits this<br />
with the serial number to the server. Activation then takes place.<br />
A response will be received indicating whether the activation has been successful.<br />
Options<br />
To make sure that the User changes their static password, extra fields can be added to the second page in this<br />
scenario. Fields can be added to the input page so that the User can enter a new static password, and then enter<br />
it again for confirmation. The User needs to do this so that the original password can only be used once, for<br />
activation. The new password can be used for re-activation. See Reactivation section below.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 78
Scenario 3 – Dynamic Registration using Back-End System<br />
Pre-conditions<br />
the User account has not been created on <strong>Identikey</strong> <strong>Server</strong><br />
the User knows their static password for their account in the Back-End system<br />
The Provisioning policy has been defined with the following settings:<br />
Software Digipass Provisioning<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 79
Local Authentication (Digipass Only or Digipass/Password)<br />
Back-End Authentication (Always or If Needed)<br />
Software Digipass Provisioning<br />
Back-End Protocol (Windows, RADIUS, LDAP Back-End authentication, or Custom name)<br />
Dynamic User Registration EnabledProcess<br />
Image 26: Digipass for Web Scenario 3 Process<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 80
Procedure<br />
Software Digipass Provisioning<br />
The procedure very similar to scenario 2; the User will not see a difference. The difference for the <strong>Identikey</strong> <strong>Server</strong><br />
is that the Back-End system is used to verify the User Id and Password. If they are OK, and account is created<br />
automatically in <strong>Identikey</strong> <strong>Server</strong>.<br />
Options<br />
To make sure that the User changes their static password, extra fields can be added to the second page in this<br />
scenario. Fields can be added to the input page so that the User can enter a new static password, and then enter<br />
it again for confirmation. The User needs to do this so that the original password can only be used once, for<br />
activation. The new password can be used for re-activation. See 4.6 Reactivation section below.<br />
4.3 DP110 Provisioning Overview<br />
4.3.1 Scenario 1<br />
The DP110 is a hardware/software combination Digipass. It does not require any software to be installed on the<br />
client side to enable it to run, but it does require the correct policy settings to be provided, followed by activation.<br />
There are two scenarios that can be employed when activating a DP110. They both have different pre-conditions.<br />
Which scenario is used will depend on how <strong>Identikey</strong> <strong>Server</strong> is implemented.<br />
Pre-Conditions<br />
User account created<br />
User knows historical secret<br />
Historical Secret imported in <strong>Identikey</strong> <strong>Server</strong> (as static password)<br />
Provisioning policy defined with following settings:<br />
Local Authentication<br />
NO Back-End authentication<br />
Digipass type is 'DP110'<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 81
Process<br />
Image 27: DP110 Scenario 1<br />
Procedure<br />
Software Digipass Provisioning<br />
The User opens the browser on his PC, and goes to the registration page of the DP110 provisioning website. The<br />
DP110 provisioning website generates a challenge which will be used to encrypt the new server PIN. The User<br />
enters their user ID, static password, new server PIN, confirmation of new server PIN, and DP110 serial number on<br />
the registration website. The DP110 Applet generates a Challenge Encrypted Static Password (CESPR) using the<br />
generated challenge and the new server PIN.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 82
4.3.2 Scenario 2<br />
Software Digipass Provisioning<br />
On the server side, the CESPR is verified. If verification is successful the DP110 is assigned to the User, and the<br />
initial PIN is set. The Digipass Grace Period is set according to pre-defined parameters. The activation page is<br />
returned if the provisioning is successful, or an error message will be returned if the provisioning is not successful.<br />
Pre-Conditions<br />
User Account NOT created<br />
User knows historical secret to allow authentication by a legacy back-end system<br />
Provisioning policy defined with the following settings:<br />
NO local authentication (None)<br />
Back-End authentication (Always)<br />
Digipass type DP110<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 83
Process<br />
Image 28: DP110 Scenario 2<br />
Software Digipass Provisioning<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 84
Procedure<br />
Software Digipass Provisioning<br />
The User enters their user ID, static password, challenge, CESPR, and DP110 serial number on the registration<br />
website. On the server side, the user is authenticated on the Back-End. If the Back-End authentication is<br />
successful the User is then registered to <strong>Identikey</strong> <strong>Server</strong> using Dynamic User Registration. The DP110 is then<br />
assigned to the User, and the initial PIN is set. The Digipass Grace Period is set according to pre-defined<br />
parameters.<br />
A response will be received indicating whether the activation has been successful.<br />
4.4 What are the steps in registration of a Software Digipass?<br />
Image 29: Steps of Software Digipass Registration<br />
4.4.1 Identify Component<br />
<strong>Identikey</strong> <strong>Server</strong> will try to identify the application from which the request for registration came. A client<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 85
4.4.2 Identify Policy<br />
Software Digipass Provisioning<br />
component record must exist for the Provisioning application and location from which it connects to the server.<br />
The component type is set as a parameter by the application; the location is the source IP address of the SOAP<br />
request.<br />
<strong>Identikey</strong> <strong>Server</strong> identifies the policy to use in the registration from the client component record and checks the<br />
validity of the policy. The following settings on the policy will not be used as they are not relevant to Provisioning.<br />
Digipass Assignment Settings<br />
Challenge Settings<br />
4.4.3 Digipass User Account Lookup and Checks<br />
<strong>Identikey</strong> <strong>Server</strong> checks the User Account to:<br />
4.4.4 Local Authentication<br />
Ensure that the User Account and Domain have been defined<br />
Perform the Windows Group Check if necessary<br />
Check whether a User Account exists<br />
Check whether the User account is disabled or locked if it already exists.<br />
Local Authentication is an optional step in Software Digipass Registration. If Local Authentication is performed a<br />
static password MUST be entered. The static password will be verified against the static password held against<br />
the User Account. If the static password is not verified or no User Account exists or the User Account exists but<br />
has no password recorded against it, the registration will fail if Back-End Authentication is not enabled.<br />
If Back-End Authentication is enabled then the Back-End system will verify the password. If the password is<br />
verified but there is no User Account in <strong>Identikey</strong> <strong>Server</strong>, an account will be created. Dynamic User Registration<br />
must be enabled for this to succeed.<br />
4.4.5 Back-End Authentication<br />
The static password will be authenticated by the Back-End system. If the Back-End System does not verify the<br />
credentials, Registration will fail.<br />
4.4.6 Digipass Assignment<br />
The Registration process will perform the following steps:<br />
Search for an applicable Digipass according to the criteria on the policy associated with the User account that<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 86
is capable of activation.<br />
Software Digipass Provisioning<br />
If one was not found, Assign the first applicable and available Digipass record to the User Account F<br />
4.4.7 Activation Code Generation<br />
4.4.8 Finalization<br />
The reactivation restrictions are checked. If this is a reactivation and reactivation is allowed, then the User Account<br />
and the Digipass record already exist in <strong>Identikey</strong> <strong>Server</strong> and will be used in the following steps.<br />
The Activation Code is generated using the first capable application in the Digipass. The Activation Code may be<br />
encrypted with the User's password if the password was not verified by Local and Back-End authentication.<br />
In the finalization step the created Users and assignment are confirmed to the Data Store. Records are written to<br />
the Audit system to record the actions that have taken place, and the results. A response is sent to the User to<br />
confirm registration or to show an error message if activation failed.<br />
4.5 What are the steps in activation?<br />
Image 30: Steps of Software Digipass Activation<br />
4.5.1 Identify Policy, Component, and Digipass User Account Lookup and Checks<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 87
Software Digipass Provisioning<br />
The activation process performs the same Identify Policy and Digipass User Account Lookup and Checks as the<br />
registration process, except that the User Account MUST already exist.<br />
4.5.2 Verify One Time Password<br />
4.5.3 Activation<br />
4.5.4 Finalization<br />
4.6 Reactivation<br />
The One Time Password is verified against the Digipass record.<br />
The Digipass is set to ACTIVE in the data store and the grace period will end, if one was set.<br />
In the Finalization step the activation is confirmed to the Data Store. Records are written to the Audit system to<br />
record the actions that have taken place, and the results. A response is sent to the User to confirm activation or<br />
show an error message if activation failed.<br />
From time to time software Digipass will have to be reactivated. This may occur rarely for Digipass for Mobile,<br />
such as when the User buys a new mobile phone, or it may occur more often for Digipass for Web, such as when<br />
the User clears the cookies in their browser<br />
Reactivation is carried out in the same way as the original activation, but the User account will already exist with a<br />
capable Digipass assigned. The registration process will use the assigned Digipass to generate the Activation<br />
Code.<br />
Configuration Settings can be set up to set the following limits:<br />
Activation Limit - this will limit the number of activations that can be performed on one Software Digipass.<br />
Minimum Interval - This sets the minimum time interval between reactivations.<br />
Maximum Locations - This sets the maximum number of locations a Software Digipass can be activated from,<br />
such as home, office, laptop. This only applies to Digipass for Web.<br />
Note<br />
The activation limits apply to all activation attempts. If an activation fails in the second stage this<br />
will still count as an activation, and will count against the activation limits.<br />
These settings are defined in the Scenarios Section of the <strong>Identikey</strong> <strong>Server</strong> Configuration<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 88
5 Administration Interfaces<br />
Administration Interfaces<br />
The main user interfaces available for administration of <strong>Identikey</strong> <strong>Server</strong> are introduced in this section.<br />
5.1 Data Administration<br />
Where <strong>Identikey</strong> <strong>Server</strong> uses an ODBC database – including the embedded PostgreSQL database – as its data<br />
store, all data administration can be carried out using the Administration Web Interface. Where <strong>Identikey</strong> <strong>Server</strong><br />
uses Active Directory as its data store, Digipass User accounts and Digipass records are administered via the<br />
Active Directory Users and Computers Snap-In, rather than the Administration Web Interface.<br />
Active Directory Users<br />
and Computers Snap-In<br />
Administration Web<br />
Interface<br />
ODBC Database - Digipass Users<br />
Digipass<br />
Policies<br />
Clients<br />
Back End <strong>Server</strong>s<br />
Organization<br />
Reports<br />
System<br />
Active Directory Digipass Users<br />
Digipass<br />
5.1.1 Administration Web Interface<br />
Policies<br />
Clients<br />
Back End <strong>Server</strong>s<br />
Reports<br />
System<br />
The Administration Web Interface is a web-based administration tool.<br />
Data available for<br />
administration in the<br />
Administration Web<br />
Interface<br />
ODBC Database Active Directory<br />
Users<br />
Digipass<br />
Policies<br />
Clients<br />
Back End <strong>Server</strong>s<br />
Organization<br />
Reports<br />
System<br />
Policies<br />
Clients<br />
Back End <strong>Server</strong>s<br />
Reports<br />
System<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 89
Note<br />
Administration Interfaces<br />
Only Administrators have access to the Administration Web Interface. If you do not have<br />
Administrator access you will not be able to use the Administration Web Interface.<br />
User Accounts<br />
If <strong>Identikey</strong> <strong>Server</strong> uses an ODBC database – including the embedded PostgreSQL database – as its data store, the<br />
Administration Web Interface can be used for the following tasks:<br />
Import Digipass User accounts singly or in bulk<br />
Create Digipass User accounts<br />
Edit Digipass User accounts<br />
Disable Digipass User accounts<br />
Delete Digipass User accounts<br />
Search for User Accounts<br />
The Administration Web Interface allows you to search for Digipass User account records in a number of ways:<br />
Search directly by entering the User ID<br />
Search for the User that a specific Digipass belongs to by searching for the Digipass and double clicking on the<br />
User on the Digipass details screen<br />
You can enter the first few characters of the User ID followed by a wildcard (*). A results list will be provided<br />
from which you can select the User required.<br />
Digipass Record Administration<br />
If <strong>Identikey</strong> <strong>Server</strong> uses an ODBC database – including the embedded PostgreSQL database – as its data store, the<br />
Administration Web Interface can be used for the following tasks:<br />
Import Digipass either individually or in bulk<br />
Create Digipass records<br />
Reset Digipass<br />
Reset PIN for a Digipass<br />
Assign Digipass<br />
Unassign Digipass<br />
Activate and deactivate applications for Digipass<br />
Unlock a Digipass<br />
Search for Digipass Records<br />
The Administration Web interface allows you to search for Digipass in a number of ways:<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 90
You can search directly for the Digipass by entering the Digipass Serial Number<br />
Administration Interfaces<br />
You can search for Digipass that belong to a User by searching on the User and then double clicking on the<br />
Digipass on the User Details Screen<br />
You can enter the first few numbers of the Digipass Serial Number followed by a wildcard (*). This will provide<br />
you with a list from which you can select the Digipass you require.<br />
Policy<br />
You can search based on the description field of a Digipass record.<br />
Policy records can be edited, created or deleted using the Administration Web Interface.<br />
New Policy records can be created using a wizard.<br />
Client Records<br />
The Administration Web Interface allow you to create, manage, and delete Client Records.<br />
Back End <strong>Server</strong> records<br />
The Administration Web Interface can be used to edit, create or delete Back End <strong>Server</strong> Records, and configure<br />
general Back End authentication settings.<br />
Domain and Organizational Unit Records<br />
Use the Administration Web Interface to add, maintain, or delete a Domain or an Organizational Unit.<br />
Reports<br />
The Administration Web Interface allows you to run existing reports and to create new reports. See 11 Reporting<br />
for more details<br />
System<br />
The System tab allows you to administer the system. You can add or remove <strong>Identikey</strong> <strong>Server</strong>s, administer the<br />
licence, configure the <strong>Identikey</strong> <strong>Server</strong> and manage administrative sessions.<br />
5.1.1.2 Starting the Administration Web Interface<br />
Ensure that the web server service (Windows) or daemon (Linux) is running. Open a browser window and type in<br />
the IP address and port number used by the Administration Web Interface. You will need to log in with an <strong>Identikey</strong><br />
<strong>Server</strong> administrator account.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 91
5.1.2 Digipass Extension for Active Directory Users & Computers<br />
Administration Interfaces<br />
The Digipass Extension for Active Directory Users and Computers allows administration of Digipass User<br />
accounts and Digipass records within the Active Directory Users and Computers interface.<br />
Note<br />
The Digipass Extension for Active Directory Users and Computers is only available where Active<br />
Directory is utilized as the data store.<br />
The extension adds context menu options, User property sheet tabs and a property sheet for the Digipass records,<br />
as outlined below.<br />
Connection<br />
No logon screen is presented by the extension - an implicit logon to Active Directory will be carried out using your<br />
current Windows user context. It will connect to the same Domain Controller as the Active Directory Users and<br />
Computers connection.<br />
The extension will make its own LDAP connection to Active Directory. Administration does not take place via the<br />
<strong>Identikey</strong> <strong>Server</strong>. Your administrative permissions will depend on the permissions that your Active Directory user<br />
account has within Active Directory.<br />
When do new settings take effect?<br />
When settings are changed with the extension, the new values may not always take effect immediately. See 2.4<br />
Active Directory Replication Issues in the Administration Reference <strong>Guide</strong> for more information.<br />
5.1.2.2 Context Menu Extensions<br />
VASCO context menu options are available on the following containers in the tree pane:<br />
The Users container<br />
All Organizational Units<br />
The Digipass-Pool, Digipass-Reserve and Digipass-Configuration containers<br />
Additional context menu options are available when right-clicking on one or more User records in the result pane:<br />
5.1.2.3 User Property Sheet Extensions<br />
Additional tabs are available when viewing the property sheet of a User record:<br />
The Digipass User Account tab contains extra information about the Digipass User account required by<br />
<strong>Identikey</strong> <strong>Server</strong>. This includes settings such as authentication policy overrides, and the date and time that a<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 92
Digipass User account was created.<br />
Administration Interfaces<br />
The Digipass Assignment tab contains information on all Digipass assigned to the Digipass User. These<br />
Digipass can be administered from this tab, including unassignment or enabling Backup Virtual Digipass.<br />
Digipass may also be assigned to the Digipass User from this tab.<br />
The Provisioning tab contains features related to the distribution and special administration of software<br />
Digipass and DP 110.<br />
5.1.2.4 Digipass Record Administration<br />
Digipass information may be viewed via the property sheet of its assigned User, or by turning on Advanced<br />
Features. This allows you – dependent on permissions - to see Digipass records wherever they are located in<br />
Active Directory (typically in the Digipass-Pool container if unassigned), view properties and use a number of<br />
context menu actions.<br />
For more details on these actions, see 7 Digipass.<br />
The context menu of the Digipass record contains options for bulk management.<br />
The property sheet for the Digipass record shows full details of the Digipass and all its Applications and enables all<br />
administration tasks for the record.<br />
Search for Digipass Records<br />
The Digipass Extension for Active Directory Users and Computers allows you to search for specific Digipass<br />
records, or Digipass records meeting set criteria. This functionality can be useful when you have Digipass records<br />
in various places throughout Active Directory.<br />
5.1.3 Digipass TCL Command-Line Administration<br />
Digipass TCL Command-Line Administration allows interactive command-line and scripted administration of<br />
Digipass related data. It has a number of possible uses:<br />
Interactive command-line administration<br />
Scripted administration<br />
Complex bulk administration tasks<br />
Reporting on the data in the data store<br />
It is an extension of the TCL 8.4 scripting language, and administrators will require a basic competence in TCL in<br />
order to use the command-line utility. See the Digipass TCL Command-Line Administration topic in the<br />
Administrator Reference for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 93
5.2 System Administration<br />
5.2.1 <strong>Identikey</strong> <strong>Server</strong> Configuration<br />
Administration Interfaces<br />
The <strong>Identikey</strong> <strong>Server</strong> uses a local XML text file for various configuration settings. This can be administered using a<br />
graphical user interface referred to as <strong>Identikey</strong> <strong>Server</strong> Configuration, or via the Administration Web Interface.<br />
To run the <strong>Identikey</strong> <strong>Server</strong> Configuration tool, go to the install directory and run <strong>Identikey</strong> <strong>Server</strong> Configuration.<br />
When settings are changed with this program, the <strong>Identikey</strong> <strong>Server</strong> must be restarted before the new values take<br />
effect. The program will do this for you when you exit.<br />
The following groups of settings are configured using <strong>Identikey</strong> <strong>Server</strong> Configuration. For more detail, see the<br />
Administrator Reference, Configuration Settings section.<br />
Communication Protocols - Set up SOAP, RADIUS, or SEAL protocols<br />
Scenarios<br />
5.2.2 Audit Viewer<br />
5.2.3 Admintool.jar<br />
Plug-ins - define your Back-End Authentication plug-in engines<br />
Database Storage - add additional ODBC databases with optional encryption settings<br />
Auditing - Enable/Disable audit methods<br />
Replication - Specify Replication settings.<br />
Use the Audit Viewer to view Audit Messages. Audit messages consist of warnings and errors generated by<br />
<strong>Identikey</strong> <strong>Server</strong>.<br />
The Admintool.jar tool can be used to configure the Administration Web Interface. It allows:<br />
Modifications to the list of <strong>Identikey</strong> <strong>Server</strong>s which may be administered from the Administration Web Interface<br />
Configuration of SSL certificates<br />
5.2.4 Configuration Wizard<br />
The Configuration Wizard is run initially after installation set-up mode. After installation it can be run in<br />
maintenance mode. Use it to change IP addresses and modify other configuration settings. See the Administrator<br />
Reference, Configuration Settings section for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 94
5.3 What do I need to use?<br />
5.3.1 Helpdesk<br />
Administration Interfaces<br />
The administration interface needed depends on the tasks required, and the data store used by <strong>Identikey</strong> <strong>Server</strong>.<br />
If <strong>Identikey</strong> <strong>Server</strong> uses an ODBC database as its data store, you will typically use the Administration Web<br />
Interface.<br />
If <strong>Identikey</strong> <strong>Server</strong> uses Active Directory as its data store, you will typically use the Digipass Extension for Active<br />
Directory Users and Computers.<br />
5.3.2 User/Digipass Administrator<br />
The main tools you will use are:<br />
Web Administration Interface<br />
Digipass Extension for Active Directory Users and Computers (AD only)<br />
Digipass TCL Command Line Administration<br />
Authentication <strong>Server</strong> Configuration<br />
5.3.3 System Administration<br />
The main tools you will use are:<br />
<strong>Identikey</strong> <strong>Server</strong> Configuration<br />
Audit Viewer<br />
Configuration Wizard<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 95
6 Digipass User Accounts<br />
6.1 Digipass User Account Creation<br />
A Digipass User account can be created in the following ways:<br />
6.1.1 Manual Creation<br />
Use the Administration Web Interface to import Users from a file<br />
Digipass User Accounts<br />
Manually create User records using the Create User function on the Administration Web Interface<br />
Dynamically during processing if Dynamic User Registration is enabled<br />
A Digipass User Account can be created manually by an administrator using the Administration Web Interface.<br />
6.1.2 Dynamic User Registration<br />
When the <strong>Identikey</strong> <strong>Server</strong> receives an authentication request for a User without a Digipass User account, it can<br />
check the credentials with the back-end authenticator (eg. Windows). If the authentication is successful with the<br />
back-end authenticator, the <strong>Identikey</strong> <strong>Server</strong> can create a Digipass User account automatically for the User. This<br />
process is called Dynamic User Registration (DUR) and can be enabled via the Administration Web Interface.<br />
This feature is commonly used in conjunction with Auto-Assignment, so that the new account is immediately<br />
assigned a Digipass.<br />
Note<br />
ODBC Database (including embedded database): If the data store is case-sensitive and the<br />
<strong>Identikey</strong> <strong>Server</strong> has not been configured to convert User IDs and Domains to upper or lower<br />
case, the potential exists for multiple Digipass User accounts to be created for a single User. For<br />
example, if a User logs in with 'jsmith' on one occasion, and JSmith on another, two Digipass<br />
User accounts may be created – jsmith and JSmith.<br />
This can be avoided by:<br />
Enabling Windows Name Resolution in the <strong>Identikey</strong> <strong>Server</strong> Configuration GUI, if the<br />
underlying user accounts are Windows user accounts. See the ODBC Connection and<br />
Domains and Organizational Units topics in the Administrator Reference for more information.<br />
This is highly recommended.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 96
Digipass User Accounts<br />
Configuring the <strong>Identikey</strong> <strong>Server</strong> to convert all User IDs and domains to upper or lower case.<br />
See the Encoding and Case-Sensitivity topic in the Administrator Reference for more<br />
information.<br />
6.2 Changes to Stored Static Password<br />
If Stored Password Proxy is enabled, any changes to a User's password on a back-end system need to be<br />
communicated to the <strong>Identikey</strong> <strong>Server</strong>. This can be done using Password Autolearn.<br />
6.2.1 Password Autolearn<br />
If Password Autolearn is enabled, a User may directly log in with their new static password in front of their OTP. If<br />
it does not match the static password stored by the <strong>Identikey</strong> <strong>Server</strong>, it can be verified with the back-end<br />
authenticator. If correct, the <strong>Identikey</strong> <strong>Server</strong> will store the new static password for future use and authenticate the<br />
User.<br />
6.3 Administration Privileges<br />
Administration of data in an ODBC database is performed through the Authentication <strong>Server</strong> to control the<br />
administrator's access to data. An administrator may be assigned permissions based on:<br />
Type of permission (eg. Read, Create)<br />
Type of object (eg. Digipass, Policy)<br />
The Domain and Organizational Unit in which the administrator account is located will determine their range of<br />
administration access:<br />
If the account belongs to an Organizational Unit, the administrator will be able to administer User accounts and<br />
Digipass belonging to that Organizational Unit.<br />
If the account does not belong to an Organizational Unit, the administrator will be able to administer all<br />
Digipass and User accounts in the Domain to which they belong.<br />
If the account belongs to the Master Domain, the administrator may be able to administer all Digipass and User<br />
accounts in the database. This depends on the 'Acces Data in All Domains' Privilege, which is only available to<br />
administrators in the Master Domain.<br />
See the Administrator Reference for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 97
7 Digipass<br />
7.1 Importing Digipass<br />
Digipass<br />
Digipass records may be imported into <strong>Identikey</strong> <strong>Server</strong> via its Administration Web Interface. Digipass can be<br />
imported either one at a time, or many can be imported at one time.<br />
The Digipass that are to be imported must be downloaded to a file in the .dpx format. The Digipass Import Wizard<br />
guides you through the steps of importing Digipass from the .dpx file. You can specify the applications that will be<br />
available with the imported Digipass, and whether the imported Digipass will be set as Active or Inactive on<br />
import. You can also specify if existing Digipass will be updated with the data from the .dpx import file.<br />
7.2 Assigning Digipass to Users<br />
Digipass may be assigned to Users in a number of ways, depending on the requirements of your company. For<br />
example, a company with only a few User accounts may use Manual Assignment. A larger company needing to<br />
distribute large numbers of Digipass may find it easier to simply distribute the Digipass and require each User to go<br />
through Self-Assignment.<br />
Note<br />
Digipass records must be imported into the data store before being assigned to Users.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 98
7.2.1 Self-Assignment<br />
Digipass<br />
A Digipass may be assigned to a User by their own action. The User must log in and include the serial number,<br />
static password and One Time Password. This informs the <strong>Identikey</strong> <strong>Server</strong> of the assignment, and provided that<br />
the User enters the details correctly, a link will be made between the Digipass record and the User account. A<br />
grace period is not used for this method.<br />
Image 31: Self Assignment Process<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 99
7.2.2 Auto-Assignment<br />
Digipass<br />
The <strong>Identikey</strong> <strong>Server</strong> can automatically assign an available Digipass when a Digipass User account is created using<br />
Dynamic User Registration (DUR). The correct Digipass must then be delivered to the User. A grace period is<br />
typically set, which allows a number of days in which the User may still log in using only their static password.<br />
Image 32: Auto Assignment Process<br />
7.2.3 Manual Assignment<br />
A selected Digipass is manually assigned to a specific Digipass User account. The Digipass must then be sent out<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 100
Digipass<br />
to the User. A grace period is typically set, during which the User may still log in using only their static password.<br />
Image 33: Manual Assignment Process<br />
7.3 Digipass Record Functions<br />
A number of functions are available to administer Digipass records. These are typically required for maintenance –<br />
eg. a User has forgotten their <strong>Server</strong> PIN, or a Digipass has been locked.<br />
7.3.1 Reset Application<br />
A Digipass Application may need to be reset if the time difference between it and the server needs to be<br />
recalculated. This would typically be for time-based Response Only Digipass after a very long period of inactivity.<br />
The 'reset' widens the allowable time window for the next login, allowing the User to log in and the <strong>Identikey</strong> <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 101
to calculate the current time shift.<br />
7.3.2 Set Event Counter<br />
7.3.3 Reset PIN<br />
Digipass<br />
If the event count for an event-based application has become unsynchronised between the Digipass and the<br />
server, this function can be used to set the server event count to the event count on the Digipass.<br />
If a User’s <strong>Server</strong> PIN needs to be changed – usually because the User has forgotten it – then it can be reset, and<br />
the User can create a new <strong>Server</strong> PIN when they next log in. This may be done when unassigning or re-assigning<br />
a Digipass.<br />
7.3.4 Force PIN Change<br />
7.3.5 Set PIN<br />
This function can be used when an administrator wants a User to change their <strong>Server</strong> PIN on their next login. This<br />
may be desirable as a security measure.<br />
A User’s <strong>Server</strong> PIN can be set to a specific value and communicated to the User.<br />
7.3.6 Unlock Digipass<br />
If a User incorrectly enters their Digipass PIN into their Digipass a predetermined number of times, the Digipass will<br />
become locked. Once locked, the assistance of an administrator will be required to unlock it. This function allows<br />
an administrator to provide the User with an Unlock Code to enter into their Digipass.<br />
7.3.7 Reset Application Lock<br />
If a User has attempted to log in with incorrect details too many times, the Digipass Application used may be<br />
locked, depending on Policy settings. This function can be used to set the record for the Digipass Application to<br />
the status of unlocked. This differs from User locking, as the User may still log in with a different Digipass.<br />
7.3.8 Test a Digipass Application<br />
Use this function to check that a Digipass Application is working as expected. There is also a function to test the<br />
Backup Virtual Digipass functionality. This works for either One Time Password or Signature.<br />
7.3.9 Reset Activation<br />
Use this function to reset the Event Counter, Activation time and Activation location on a Digipass.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 102
7.4 Digipass Programming<br />
7.4.1 Digipass PIN<br />
Digipass<br />
A Digipass is programmed using a Digipass Programmer and the necessary software. This may be done by your<br />
company or by your supplier.<br />
Common settings which may affect your administration tasks are explained below.<br />
A Digipass PIN may be required for a Digipass. If set, the PIN must be entered into the Digipass before obtaining a<br />
One Time Password. This means that just possessing the Digipass is not enough to log in to a network – the<br />
person logging in must also know the Digipass PIN.<br />
Digipass PIN settings include:<br />
An Initial PIN can be set for a Digipass. The PIN must then be sent to the User of the Digipass, typically<br />
separate from the Digipass delivery.<br />
First Use PIN Modification allows a Digipass to require a PIN change from the User upon first use.<br />
PIN Change allows a User to change their PIN as desired.<br />
The PIN Length can be set for a Digipass.<br />
Digipass Lock sets the number of consecutive faulty PIN entries allowed before the Digipass is locked.<br />
7.4.2 Time/Event-based Digipass Applications<br />
Response Only<br />
Response Only Digipass Applications can be either time-based or event-based:<br />
Time-based<br />
A time-based Application will change the OTP to be displayed based on the current time. The common time step<br />
used is 36 seconds – and means that the OTP to be displayed will change every 36 seconds, whether or not an<br />
OTP has been requested from the Digipass.<br />
Event-based<br />
An event-based Digipass Application will display a new OTP each time a request for an OTP is made.<br />
Challenge/Response<br />
Challenge/Response Digipass Applications can be either time-based or non-time-based:<br />
Time-based<br />
A time-based Challenge/Response Digipass Application will generate an OTP based on the Challenge given and the<br />
current time. The common time step used is 9 hours ('slow challenge'). This would mean that if the exact same<br />
Challenge were given to a Digipass within a 9 hour period, the Digipass Application will generate the same OTP.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 103
However, Challenges are very rarely repeated within such a time period.<br />
Non-time-based<br />
Digipass<br />
A non-time-based Challenge/Response Digipass Application will generate an OTP based only on the Challenge<br />
given.<br />
Signature<br />
Time-based<br />
The signature application may be time based. This means that the Digipass will generate a different signature for<br />
the same input data at different times.<br />
Event-based<br />
7.4.3 OTP Length<br />
The signature application may be event based. This means that it contains a numeric counter that increases every<br />
time a signature is generated.<br />
Neither Time- nor Event-based<br />
These signatures are generated using neither time or event counter. They will always produce the same signature<br />
for the same input. There is no difference between real-time and deferred time with these signatures.<br />
The length of the OTP (excluding check digit) generated by the Digipass for Response Only and<br />
Challenge/Response Digipass Applications.<br />
Check Digit<br />
A check digit may be added to each OTP. This is generated from the response and allows for faster invalidation of<br />
incorrect OTPs.<br />
7.4.4 Challenge Length<br />
The length of the Challenge (excluding check digit) which should be expected by the Digipass. This is used by the<br />
Challenge/Response Digipass Application.<br />
Check Digit<br />
A check digit may be expected with each Challenge. This is generated by the server from the Challenge and<br />
allows the Digipass to reject most invalid Challenges.<br />
7.4.5 Signature Length<br />
The length of the Signature generated by the Digipass.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 104
7.4.6 Signature Data Fields<br />
Digipass<br />
These are the data fields that may be provided when signing a transaction. There may be from 1 to 8 fields, each<br />
with a minimum length of 0 and a maximum length of 16.<br />
Check Digit<br />
A check digit is optional.<br />
7.5 Digipass Record Settings<br />
These settings are kept in the record for a Digipass Application, and affect which OTP is expected by the <strong>Identikey</strong><br />
<strong>Server</strong>.<br />
7.5.1 Time/Event-based Settings<br />
Time Step Used<br />
The time step used by the Digipass Application (see Time/Event-based Digipass Applications for more information).<br />
Last Time Shift<br />
Time Shift records any misalignments between the time recorded on the Digipass and the time recorded on the<br />
server, each time a User logs in. This ensures that if either clock drifts from the correct time, an allowance can be<br />
made by the <strong>Identikey</strong> <strong>Server</strong> and the User will still be able to log in. If the time drift goes beyond the allowable<br />
time window between User logins, the Digipass record will have to be reset (this allows for recalculation of the time<br />
drift).<br />
Example<br />
Time window may be 5 steps in either direction.<br />
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<br />
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<br />
logs in, the expected OTP will be calculated based on that time shift.<br />
Last Event Value<br />
The current number of uses of the Digipass Application, according to the Digipass. This can get out of sync with<br />
the number of uses recorded by the <strong>Identikey</strong> <strong>Server</strong> when:<br />
Login failures occur for other reasons than incorrect OTP<br />
The Digipass has been used without a login (eg. children have been playing with it)<br />
The Digipass is being used to log in to two separate systems<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 105
7.5.2 <strong>Server</strong> PIN<br />
Digipass<br />
The purpose of this setting is much the same as the Last Time Shift setting – it allows the <strong>Identikey</strong> <strong>Server</strong> to track<br />
any shifts between the event count recorded by itself and the Digipass.<br />
The term '<strong>Server</strong> PIN' is used to mean a PIN that the user enters into the login password field in front of the OTP<br />
displayed on the Digipass. It is checked by the authenticating server. The 'Digipass PIN' referred to earlier indicates<br />
a PIN entered into a keypad on the Digipass. That is checked by the device itself, and is never transmitted to the<br />
server.<br />
There are a number of <strong>Server</strong> settings regulating <strong>Server</strong> PINs:<br />
PIN Supported<br />
Whether a PIN must be included in a User's login.<br />
PIN Change On<br />
Is a User allowed to change their <strong>Server</strong> PIN for this Digipass?<br />
Force PIN Change<br />
Must the User change their <strong>Server</strong> PIN the next time they log in?<br />
PIN Length<br />
The length of the current <strong>Server</strong> PIN.<br />
PIN Minimum Length<br />
The minimum PIN length required by the <strong>Server</strong>.<br />
7.5.3 Backup Virtual Digipass<br />
Policy and Digipass settings<br />
Several settings dictate how a User may utilize the Backup Virtual Digipass feature. These settings are:<br />
Enable or disable Backup Virtual Digipass and enable method (eg. Required).<br />
Time limit/expiry (applies to Time Limited enable only)<br />
Maximum number of times a User may make use of the Backup Virtual Digipass.<br />
The above settings may be set both at the Policy level and at the Digipass record level. Individual settings override<br />
Policy settings for an individual Digipass, but some Policy settings (see below) may be used to automatically set<br />
Digipass settings which are blank when the Backup Virtual Digipass is first utilized by the User.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 106
Time Limit and Max. Uses/User<br />
Policy Setting Digipass Setting<br />
Time Limit Enabled Until<br />
Max. Uses/User Uses Remaining<br />
Table 1: Backup Virtual Digipass Policy/Digipass Settings<br />
Digipass<br />
If Backup Virtual Digipass is enabled for a Digipass and set to Time Limited, and the Enabled Until field in the<br />
Digipass property sheet is blank on their first use of the Backup Virtual Digipass, their time limit will begin on their<br />
first use of the feature. The expiry date (today’s date + Time Limit) will then be displayed in the Enabled Until<br />
field.<br />
If a Max. Uses/User is set for the relevant Policy and a Digipass record's Uses Remaining field in their User<br />
property sheet is blank on their first use of the Backup Virtual Digipass, a number (Max Uses/User) will be<br />
automatically entered into their Uses Remaining field and immediately decremented by 1.<br />
Note<br />
If a User has Backup Virtual Digipass enabled with Enabled Until date set and their Uses<br />
Remaining has been set (automatically or manually), whichever of these expires first will disable<br />
Backup Virtual Digipass for the User.<br />
eg. Backup Virtual Digipass is enabled for a User as Time Limited, and the server Time Limit<br />
setting is 3 days. The Max. Uses/User Policy setting is 5. When the User first makes use of<br />
the Backup Virtual Digipass, their Enabled Until is set to a date 3 days hence and their Uses<br />
Remaining to 4. During the next 48 hours, they log in 4 more times. Although the User’s time<br />
limit does not run out for another 24 hours, their Uses Remaining is now 0 and Backup Virtual<br />
Digipass is disabled.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 107
7.6 Virtual Digipass Implementation Considerations<br />
7.6.1 Digipass Assignment Options<br />
7.6.2 Cost<br />
7.6.3 Security<br />
Digipass<br />
With the introduction of Virtual Digipass, there are several different assignment combinations that can be used.<br />
The first option in the table below does not utilize Virtual Digipass. The others include a Virtual Digipass in either a<br />
backup or primary mode.<br />
Primary Backup<br />
Digipass None User must log in using a Digipass.<br />
Digipass Backup Virtual Digipass User usually logs in using a Digipass, but may utilize the Backup<br />
Virtual Digipass feature where required. Usage of the feature may<br />
be limited.<br />
Digipass (temporarily<br />
disallowed)<br />
Backup Virtual Digipass User must log in using the Backup Virtual Digipass feature. This<br />
might be used while a User’s Digipass is lost, until the Digipass is<br />
recovered.<br />
Primary Virtual Digipass N/A User is assigned a Virtual Digipass and must log in using it.<br />
Table 2: Digipass Options<br />
7.6.4 Convenience<br />
Your company will probably need to pay an amount for each text message sent. In some countries, mobile phone<br />
owners might need to pay an amount for each text message received on their mobile phone. This will need to be<br />
taken into consideration when deciding how to implement Virtual Digipass functionality.<br />
Hardware Digipass devices provide the highest level of security. Virtual Digipass provides a lower, although still<br />
high, level of security. This needs to be weighed against other considerations before deciding whether your<br />
company will implement Virtual Digipass, and if so, how it will be implemented.<br />
Virtual Digipass is more convenient than a hardware Digipass for many Users. Only one’s usual mobile phone is<br />
required: there are no extra devices to carry around. Users who do not habitually carry their mobile phone with<br />
them, though, are likely to find a GO 3 or GO 1 easier to transport.<br />
For Users with the Backup Virtual Digipass enabled, it might be the difference between going to work to pick up a<br />
forgotten Digipass and getting important work done at home.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 108
7.6.5 Gateway and account<br />
Digipass<br />
Your company will need the use of an text message gateway and an account with the gateway. The Message<br />
Delivery Component will need configuration information for the gateway and the Username and password for the<br />
account. Your VASCO supplier can assist with this process.<br />
7.6.6 Limiting Usage of Virtual Digipass<br />
Use of Virtual Digipass may be limited by:<br />
Using Backup Virtual Digipass only.<br />
Minimizing the number of Users assigned a Primary Virtual Digipass.<br />
A User’s Primary Virtual Digipass use cannot be limited.<br />
The Backup Virtual Digipass feature may be enabled as an ‘emergency’ backup for Users who have left their<br />
primary Digipass at home, or for other reasons do not have access to their primary Digipass. Use of this feature<br />
can be limited for each Digipass by:<br />
Time period<br />
Set a time period in which a User may access the Backup Virtual Digipass. After this period has expired, any<br />
Virtual Digipass requests from the User will be rejected. If the User is still unable to use their Digipass, the time<br />
period must then be extended by an administrator. Once they have started using their Digipass again, the<br />
administrator must reset the time period if the User is to be allowed to use Backup Virtual Digipass again.<br />
Number of Uses<br />
Set a maximum number of times a User may request an OTP using the Backup Virtual Digipass feature. When the<br />
User has reached this number of uses, any further OTP requests from the User will be rejected. This must be reset<br />
by an administrator if further use of the Backup Virtual Digipass is required for the User.<br />
Global and Individual Backup Virtual Digipass settings<br />
Backup Virtual Digipass options can be set globally or individually, to allow a standard policy for all Digipass with<br />
exceptions made where necessary. Global settings will affect all Digipass whose individual option is set to<br />
'Default'.<br />
Global options are defined in the Policy that controls authentication. Therefore, by using multiple Policies, you have<br />
some additional flexibility.<br />
7.6.6.2 Backup Virtual Digipass Usage <strong>Guide</strong>lines<br />
Some questions which will need to be answered before arriving at a Backup Virtual Digipass usage guidelines are:<br />
Will any users have access to Backup Virtual Digipass?<br />
If so, will all users have access to Backup Virtual Digipass?<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 109
Will usage of Backup Virtual Digipass be limited? If so, how?<br />
Time-limited?<br />
Limited number of uses?<br />
Some Possible <strong>Guide</strong>lines<br />
<strong>Guide</strong>line Pro Con<br />
Backup Virtual Digipass disabled for all -<br />
enabled for individual Users as required.<br />
Backup Virtual Digipass enabled for all -<br />
either time/number of usage limit set.<br />
Backup Virtual Digipass enabled for all -<br />
no limits set.<br />
Table 3: Backup Virtual Digipass Example <strong>Guide</strong>lines<br />
7.6.7 Resetting Virtual Digipass Restrictions<br />
Low text message costs Manual enable for each User and<br />
circumstance. Possible heavy<br />
administration load.<br />
Digipass<br />
Predictable text message costs Administrator may need to reset limits<br />
frequently – medium administration<br />
load.<br />
Lighter administration load Possible high text message costs.<br />
When a User has reached their limit of Virtual Digipass use, an administrator must reset their limit.<br />
7.6.8 Virtual Digipass Login options<br />
A decision must be made as to how Users will log in using Virtual Digipass. In particular, Users with a hardware<br />
Digipass and the Backup Virtual Digipass enabled must be able to request an OTP to be sent to their mobile when<br />
required, but to login using the hardware Digipass at other times.<br />
The simplest method for the User is to allow a 2-step login process, where the User enters their User ID and<br />
password only, triggering an OTP Request, and are redirected to a second login page to enter the OTP sent to<br />
them. To use this method, though, your system must be set up to allow 2-step logins. Check with your system<br />
administrator if unsure.<br />
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<br />
OTP, separate from the login page screen.<br />
See the Administrator Reference for information on possible login permutation.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 110
8 Client Components<br />
8.1 Component Types<br />
8.1.1 SOAP Client Programs<br />
Client Components<br />
SOAP client programs will not be called 'SOAP clients' . The program itself specifies the type, as a parameter to<br />
each request. A client component record must exist for this type at the location (IP address) where the application<br />
runs. The policy in the component record will be used for all processing of requests from this client.<br />
8.1.2 Administration Program<br />
8.1.3 RADIUS Client<br />
Creating a Component record for a VASCO administration program - either the Web Administration Interface or the<br />
Audit Viewer - allows a Policy to be set for connections from that program.<br />
A Component record MUST exist for each Web Administration Interface or any other administration program<br />
using SOAP.<br />
For the <strong>Identikey</strong> <strong>Server</strong> SEAL interface for TCL and the Audit Viewer, SEAL Require administration client<br />
component registration configuration setting determines whether an Administration Program component must<br />
be provided or not.<br />
A RADIUS Client Component record is required when clients will be sending authentication requests to the<br />
<strong>Identikey</strong> <strong>Server</strong> using the RADIUS protocol. The <strong>Identikey</strong> <strong>Server</strong> will check the Component record to find:<br />
The Shared Secret to use in communicating with the RADIUS Client.<br />
The Policy to apply to the authentication request.<br />
A default RADIUS Client Component record is automatically created during installation of <strong>Identikey</strong> <strong>Server</strong>. This can<br />
be deleted and specific records created for each location.<br />
Note<br />
The default RADIUS Client created during installation will be given a Shared Secret of default.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 111
8.1.4 IIS Module<br />
Client Components<br />
A Component record is required for any IIS Modules used with <strong>Identikey</strong> <strong>Server</strong>. The Component record will be<br />
checked whenever the IIS Module sends an authentication request to the <strong>Identikey</strong> <strong>Server</strong>. The <strong>Identikey</strong> <strong>Server</strong><br />
will check:<br />
That the Component record contains a valid License Key for a Client module<br />
Which Policy to apply to the authentication request<br />
The following client types fall under this category:<br />
Citrix Web Interface<br />
Outlook Web Interface<br />
IIS 6 Module<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 112
9 <strong>Server</strong> Components<br />
9.1 <strong>Server</strong> Component<br />
<strong>Server</strong> Components<br />
A <strong>Server</strong> Component record holds the License Key for a specific <strong>Identikey</strong> <strong>Server</strong>. This Component record will be<br />
checked when the <strong>Identikey</strong> <strong>Server</strong> is started. The <strong>Identikey</strong> <strong>Server</strong> will check for:<br />
License Key. If the License Key is missing, invalid or expired, all authentication except for administration logons<br />
will be refused. The following items need to be supported in the Licence Key:<br />
RADIUS<br />
SOAP<br />
Authentication scenario<br />
Signature Validation scenario<br />
Provisioning scenario<br />
The Policy to use for SEAL administration logins. If an ODBC database (including the embedded PostgreSQL<br />
database) is used as the data store, the Policy will be applied to all administration logins (including live audit<br />
connections) for which an Administration Program Component record is not found.<br />
A <strong>Server</strong> Component record is automatically created for each <strong>Identikey</strong> <strong>Server</strong> as it is installed.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 113
10 Policies<br />
10.1 Policy Inheritance<br />
Policies<br />
Policies may be set up in a hierarchy, where one Policy will inherit most of its attributes from a parent Policy, but<br />
with some modifications for a slightly different scenario.<br />
Image 34: Policy Inheritance<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 114
Policies<br />
In the example above, all attributes are inherited from the parent Policy. The attributes shown in the child policies<br />
above are explicitly set, which make the policy different from the parent policy. The explicitly set attributes in the<br />
child policies override those of the parent policies.<br />
10.1.1 Show Effective Settings<br />
As the various levels of settings in Policy inheritance can get confusing, functionality is available which allows you<br />
to view the settings effective for a selected Policy, taking inherited settings into account. The text below shows the<br />
effective settings for the <strong>Identikey</strong> <strong>Server</strong> RADIUS Self-Assignment Policy:<br />
Effective Policy Settings<br />
[Local/Back-End Authentication]<br />
Local Authentication : Digipass/Password<br />
Back-End Authentication : Always<br />
Back-End Protocol : RADIUS<br />
User Accounts]<br />
Dynamic User Registration : Yes<br />
Password Autolearn : Yes<br />
Stored Password Proxy : Yes<br />
Default Domain: (none)<br />
User Lock Threshold : 3<br />
[Windows Group Check]<br />
Group Check Option : No Check<br />
Group List: (none)<br />
[Digipass Assignment]<br />
Assignment Mode : Self-Assignment<br />
Grace Period (days) : 0<br />
Serial No. Separator : |<br />
Search up Organizational Unit Hierarchy : Yes<br />
[Digipass Settings]<br />
Application Names<br />
Application Type : No Restriction<br />
Digipass Types<br />
PIN Changed Allowed : Yes<br />
[1-Step Challenge Response]<br />
Enabled : No<br />
Challenge Length : 0<br />
Challenge Check Digit : No<br />
[2-Step Challenge Response]<br />
Request Method : Keyword<br />
Request Keyword<br />
[Primary Virtual Digipass]<br />
Request Method : Password<br />
Request Keyword<br />
[Backup Virtual Digipass]<br />
Enabled : No<br />
Maximum Days : 0<br />
Maximum Uses : 0<br />
Request Method : KeywordPassword<br />
Request Keyword : otp<br />
[Digipass Control Parameters]<br />
Identification Time Window : 20<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 115
Policies<br />
Signature Time Window:24<br />
Event Window : 20<br />
Initial Time Window : 6<br />
Identification Threshold : 0<br />
SignatureThreshold : 0<br />
Check Challenge Flag : 1<br />
Level of Online Signature : 0<br />
Allowed Inactive Days : 0<br />
You will note that the settings listed above include those set in Policies from which the <strong>Identikey</strong> <strong>Server</strong> RADIUS<br />
Self-Assignment Policy inherits.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 116
10.2 Pre-Loaded Policies<br />
Policies<br />
These Policies are created for the <strong>Identikey</strong> <strong>Server</strong> on installation of the <strong>Identikey</strong> <strong>Server</strong>. They provide an example<br />
for setting up Policies in a typical environment.<br />
Table 4: Pre-Loaded Policies<br />
Policy Name Parent Policy Description Non-Default Settings<br />
Base Policy - Globally applicable settings. In<br />
general, all other Policies should<br />
inherit from this, directly or<br />
indirectly.<br />
<strong>Identikey</strong> Administration<br />
Logon<br />
Base Policy Settings for an administration<br />
logon including Audit Viewer live<br />
connection. Separated from the<br />
main authentication policies to<br />
avoid accidental interference.<br />
Locking is off to reduce the<br />
chance of a lock-out.<br />
User Lock Threshold=3<br />
PIN Change Allowed=Yes<br />
Challenge Request Method=Keyword<br />
Primary VDP Request<br />
Method=Password<br />
Backup VDP Request<br />
Method=KeywordPassword<br />
Backup VDP Request Keyword=otp<br />
Identification Time Window=20<br />
Check Challenge Mode=1<br />
Event Window=20<br />
Sync Window=6<br />
Online Signature Level= 0<br />
Identification Threshold=0<br />
Local Authentication=None<br />
Back-End Authentication=None<br />
DUR=No<br />
Password Autolearn=No<br />
Stored Password Proxy=No<br />
Group Check Mode=No Check<br />
Assignment Mode=Neither<br />
Search Up OU Path=No<br />
Application Types=No Restriction<br />
1-Step Challenge/Response=No<br />
1-Step Challenge Check Digit=No<br />
Backup VDP Enabled=No<br />
Local<br />
Authentication=Digipass/Password<br />
User Lock Threshold=0<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 117
Policy Name Parent Policy Description Non-Default Settings<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Windows<br />
Password Replacement<br />
<strong>Identikey</strong> Microsoft AD<br />
Password Replacement<br />
<strong>Identikey</strong> Novell e-<br />
Directory Password<br />
Replacement<br />
<strong>Identikey</strong> Microsoft<br />
ADAM Password<br />
Replacement<br />
<strong>Identikey</strong> Windows<br />
Auto-Assignment<br />
<strong>Identikey</strong> Microsoft AD<br />
Auto Assignment<br />
Base Policy Settings applicable to all <strong>Identikey</strong><br />
<strong>Server</strong> authentication Policies,<br />
including local authentication. In<br />
general, all other <strong>Identikey</strong> <strong>Server</strong><br />
Policies using local authentication<br />
should inherit from this, directly or<br />
indirectly.<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Windows<br />
Password<br />
Replacement<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> <strong>Server</strong> model for<br />
password replacement and<br />
Dynamic User Registration, using<br />
Windows back-end authentication<br />
and a Windows group check.<br />
<strong>Identikey</strong> <strong>Server</strong> model for<br />
password replacement for<br />
Microsoft Active Directory<br />
<strong>Identikey</strong> <strong>Server</strong> model for<br />
password replacement for Novell<br />
e-Directory<br />
Identiky <strong>Server</strong> model for<br />
password replacement for<br />
Microsoft ADAM<br />
<strong>Identikey</strong> <strong>Server</strong> model for Auto-<br />
Assignment based on the<br />
Windows password replacement<br />
model.<br />
<strong>Identikey</strong> <strong>Server</strong> model for Auto<br />
Assignment for Microsoft Active<br />
Directory<br />
Local<br />
Authentication=Digipass/Password<br />
Back-End Authentication=Always<br />
Back-End Protocol=Windows<br />
DUR=Yes<br />
Assignment Mode=Neither<br />
Group Check Mode=Pass Back<br />
Group List=Digipass Users<br />
Password Autolearn=Yes<br />
Stored Password Proxy=Yes<br />
Local Auth=Default<br />
Backend Auth=Always<br />
Backend Protocol=Microsoft AD<br />
DUR=Yes<br />
Password Autolearn=Yes<br />
Stored Password Proxy=Yes<br />
Policies<br />
Local Auth=Default<br />
Backend Auth=Always<br />
Backend Protocol=Novell e-Directory<br />
DUR=Yes<br />
Password Autolearn=Yes<br />
Stored Password Proxy=Yes<br />
Local Auth=Default<br />
Backend Auth=Always<br />
Backend Protocol=Microsoft ADAM<br />
Password Autolearn=Yes<br />
Stored Password Proxy=Yes<br />
Assignment Mode=Auto-Assignment<br />
Search Up OU Path=Yes<br />
Grace Period=7<br />
Local Auth=Default<br />
Backend Auth=If Needed<br />
Backend Protocol=Microsoft AD<br />
Assignment Mode=Auto-Assignment<br />
Search-Up-OU-Path=Yes<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 118
Policy Name Parent Policy Description Non-Default Settings<br />
<strong>Identikey</strong> Microsoft<br />
ADAM Auto Assignment<br />
<strong>Identikey</strong> Windows Self-<br />
Assignment<br />
<strong>Identikey</strong> Microsoft AD<br />
Self Assignment<br />
<strong>Identikey</strong> Microsoft<br />
ADAM Self Assignment<br />
<strong>Identikey</strong> Novell e-<br />
Directory Self<br />
Assignment<br />
<strong>Identikey</strong> RADIUS<br />
Password Replacement<br />
<strong>Identikey</strong> RADIUS Auto-<br />
Assignment<br />
<strong>Identikey</strong> RADIUS Self-<br />
Assignment<br />
<strong>Identikey</strong> Back-End<br />
Authentication<br />
<strong>Identikey</strong> Microsoft<br />
ADAM Password<br />
Replacement<br />
<strong>Identikey</strong> Windows<br />
Password<br />
Replacement<br />
<strong>Identikey</strong> Microsoft<br />
AD Password<br />
Replacement<br />
<strong>Identikey</strong> Microsoft<br />
ADAM Password<br />
Replacement<br />
<strong>Identikey</strong> Novell e-<br />
Directory Password<br />
Replacement<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> Local<br />
Authentication<br />
<strong>Identikey</strong> <strong>Server</strong> model for Auto<br />
Assignment for Microsoft ADAM<br />
<strong>Identikey</strong> <strong>Server</strong> model for Self-<br />
Assignment based on the<br />
Windows password replacement<br />
model.<br />
<strong>Identikey</strong> <strong>Server</strong> model for Self-<br />
Assignment for AD Password<br />
Replacement<br />
<strong>Identikey</strong> <strong>Server</strong> model for Self-<br />
Assignment for ADAM Password<br />
Replacement<br />
<strong>Identikey</strong> <strong>Server</strong> model for selfassignment<br />
for Novell e-Directory<br />
<strong>Identikey</strong> <strong>Server</strong> model for<br />
password replacement and<br />
Dynamic User Registration using a<br />
RADIUS server for back-end<br />
authentication.<br />
<strong>Identikey</strong> <strong>Server</strong> model for Auto-<br />
Assignment based on the RADIUS<br />
password replacement model.<br />
<strong>Identikey</strong> <strong>Server</strong> model for Self-<br />
Assignment based on the RADIUS<br />
password replacement model.<br />
Base Policy <strong>Identikey</strong> <strong>Server</strong> model for only<br />
Back-End Authentication. Change<br />
the back-End Protocol to the one<br />
required.<br />
Policies<br />
Local Auth = Default<br />
Backend Auth = If Needed<br />
Backend Protocol = Microsoft ADAM<br />
Assignment Mode = Auto-Assignment<br />
Search-Up-OU-Path = Yes<br />
Assignment Mode=Self-Assignment<br />
Search Up OU Path=Yes<br />
Self Assignment Separator=|<br />
Local Auth = Default<br />
Backend Auth = Always<br />
Backend Protocol = Microsoft AD<br />
Assignment Mode = Self-Assignment<br />
Search-Up-OU-Path = Yes<br />
Local Auth = Default<br />
Backend Auth = If Needed<br />
Backend Protocol = Microsoft ADAM<br />
Assignment Mode = Self-Assignment<br />
Search-Up-OU-Path = Yes<br />
Local Auth = Default<br />
Backend Auth = Always<br />
Backend Protocol = Novell e-Directory<br />
Assignment Mode = Self-Assignment<br />
Search-Up-OU-Path = Yes<br />
Backend Authentication=Always<br />
Backend Protocol=RADIUS<br />
Password Autolearn=Yes<br />
Stored Password Proxy=Yes<br />
Grace Period=7<br />
Search Up OU Path=Yes<br />
Assignment Mode=Self-Assignment<br />
Search Up OU Path=Yes<br />
Assignment Mode=Self-Assignment<br />
Self Assignment Separator=|<br />
Backend Protocol=RADIUS<br />
Backend Authentication=Always<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 119
Policy Name Parent Policy Description Non-Default Settings<br />
<strong>Identikey</strong> DP110<br />
Provisioning 1<br />
<strong>Identikey</strong> DP110<br />
Provisioning 2<br />
<strong>Identikey</strong> DP4Mobile<br />
Register<br />
<strong>Identikey</strong> DP4Web<br />
Provisioning 1<br />
<strong>Identikey</strong> DP4Web<br />
Provisioning 2<br />
<strong>Identikey</strong> DP4Web<br />
Provisioning 3<br />
<strong>Identikey</strong> Deferred Time<br />
signature Verfication<br />
<strong>Identikey</strong> Real-Time<br />
signature verfication 1<br />
<strong>Identikey</strong> Real-Time<br />
signature verfication 2<br />
<strong>Identikey</strong> Real-Time<br />
signature verfication 3<br />
Base Policy <strong>Identikey</strong> Digipass for Web<br />
Provisioning model scenario 1 -<br />
Activation codes are encrypted<br />
with pre-loaded static passwords.<br />
Base Policy <strong>Identikey</strong> DP110 Provisioning<br />
model scenario 2 - Dynamic<br />
Registration using Back-End<br />
System. Change the Back-End<br />
Protocol to the one required.<br />
Base Policy <strong>Identikey</strong> Digipass for Mobile<br />
Register - pre-loaded User<br />
accounts and static passwords.<br />
Base Policy <strong>Identikey</strong> Digipass for Web<br />
Provisioning model scenario 1 -<br />
Activation codes are encrypted<br />
with pre-loaded static passwords.<br />
Base Policy <strong>Identikey</strong> Digipass for Web<br />
Provisioning model scenario 2 -<br />
pre-loaded User accounts and<br />
static passwords.<br />
Base Policy <strong>Identikey</strong> Digipass for Web<br />
Provisioning model scenario 3 -<br />
Dynamic Registration using Back-<br />
End System. Change the Back-End<br />
Protocol to the one required.<br />
Base Policy Deferred time signature<br />
verification settings: Time based.<br />
Base Policy Real-time signature verification<br />
settings: Time-based, several<br />
signatures are allowed in the same<br />
timestep but 2 identical<br />
successive signatures will be<br />
rejected.<br />
Base Policy Real-time signature verification<br />
settings: Time-based, one<br />
signature allowed per timestep.<br />
Base Policy Deferred time signature<br />
verification settings: Event based,<br />
off-line mode.<br />
Policies<br />
Local Auth = Digipass/Password<br />
1-Step Challenge/Response=Yes-Any<br />
challenge<br />
Local Auth = Digipass/Password<br />
Back-End Authentication = Always<br />
1-Step Challenge/Response=Yes – Any<br />
challenge<br />
Online Signature Level = 1 Multiple<br />
Signatures allowed in same Time Step<br />
Local Auth = Digipass/Password<br />
Local Auth = Digipass/Password<br />
DUR=Yes<br />
Signature Time Window = 24<br />
Online signature level = 1 - Multiple<br />
Signatures allowed in same Time Step<br />
Online signature level = 2 - Only 1<br />
Signature/Time Step allowed<br />
Signature Time Window = 24<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 120
11 Reporting<br />
11.1 Reporting Overview<br />
Image 35: Reporting Structure<br />
Reporting<br />
The <strong>Identikey</strong> <strong>Server</strong> Reporting facility allows you to create reports from the <strong>Identikey</strong> <strong>Server</strong> database information,<br />
and from the Audit information.<br />
The main uses for reports are:<br />
Troubleshooting<br />
User Troubleshooting – administrators can generate reports to enable them to troubleshoot authentication<br />
failures for specific users.<br />
System Troubleshooting – system administrators can generate <strong>Identikey</strong> <strong>Server</strong> reports to analyse and<br />
solve system problems<br />
System Audits<br />
System administrators can generate reports to carry out audits of Digipass or administrator actions.<br />
Security Audits<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 121
System administrators can generate reports to analyse suspicious activity.<br />
Accounting<br />
Reports can be generated to count the number of authentication requests per user or organizational unit.<br />
Reporting<br />
A number of standard reports are available, but if the report you require is not among them you can create your<br />
own (custom) report.<br />
11.2 Report Definition<br />
Reports are made up of the following elements:<br />
Report Type<br />
Data Store<br />
Grouping Level<br />
Query<br />
11.2.1 Report Type<br />
Formatting Template<br />
These elements combine to produce a report. They are present for standard reports, and you can select properties<br />
from each of these elements to create a custom report.<br />
There are four report types. All reports are based on these report types.<br />
List Analysis Report<br />
Detailed Analysis Report<br />
Distribution Analysis Report<br />
Trend Analysis Report.<br />
The List Analysis Report lists all items that match the criteria specified in the report definition. For example, a list<br />
of users with no Digipass assigned.<br />
The Detailed Analysis Report shows detail of the events specified in the report definition. For example, a detailed<br />
list of failed authentications for a User.<br />
The Distribution Analysis Report will show counts of events and objects. For example, the number of failed<br />
authentications for a domain.<br />
The Trend Analysis Report shows a trend over a period of time for a the objects specified in the report definition.<br />
For Trend Analysis Reports there is an extra parameter. The period of time for which the data needs to be<br />
extracted must be specified. The choice is:<br />
Hour<br />
Day<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 122
Month<br />
Year<br />
11.2.2 Data Source<br />
11.2.3 Grouping Level<br />
Reporting<br />
Each report, whether standard or custom, will be based on these report types. Each report type retrieves its<br />
information from either the audit data, the Data Store, or from both sources.<br />
Each report is generated from data existing on <strong>Identikey</strong> <strong>Server</strong>. The choices for Data Source are as follows:<br />
Users. This will generate the report based on the User information from the <strong>Identikey</strong> <strong>Server</strong> Data Store.<br />
Users + Audit Data. This will generate the report based on the User information mentioned above, and the<br />
Audit Data from <strong>Identikey</strong> <strong>Server</strong>.<br />
Digipass. This will generate the report based on the Digipass information from the <strong>Identikey</strong> <strong>Server</strong> Data Store.<br />
Digipass + Audit Data. This will generate the report based on the Digipass information mentioned above, and<br />
the Audit Data from <strong>Identikey</strong> <strong>Server</strong>.<br />
Audit Data only. This will generate the report based on the Audit data only.<br />
The Grouping Level specifies how the data in the report will be grouped. The Grouping Level choices are:<br />
Client<br />
Domain<br />
Organizational Unit<br />
User<br />
Digipass<br />
If a Detail or List report is set at Grouping Level of User, each user will be represented individually. If a Detail or<br />
List report is set at Grouping Level of Organizational Unit, the data for all the Users in that Organizational Unit will<br />
be added together and represented only once under the Organizational Unit.<br />
In the example below, the Grouping Level has been set to User, because each User has an individual row on the<br />
report.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 123
11.2.4 Query<br />
Image 36: Report Grouping<br />
Reporting<br />
The Query specifies the search criteria that are used when the data is extracted from the Data Store or Audit Data.<br />
For example, to generate a report for a specific Audit message, such as 'Authentication' or 'DP4WEB', you can<br />
specify in your Query that Audit Message = 'Authentication'. Then you will only receive information on<br />
'Authentication' Audit Messages in your report.<br />
It is possible to add further query criteria just for one run of a report.<br />
Queries can be simple, as the query above, or they can be a combination of criteria, such as Audit Message =<br />
'Authentication', User Name = 'User5'.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 124
11.2.5 Formatting Templates<br />
Reporting<br />
Report data is always generated into XML, then an XSLT transformation is applied to give the output. The XSLT<br />
transformation requires a formatting template. Each report definition requires at least one template so that it can<br />
be produced in the format required. Each report definition can have more than one Formatting Template. The<br />
template to be used can be selected when running the report.<br />
11.3 Standard Reports<br />
The <strong>Identikey</strong> <strong>Server</strong> reporting package will come with standard reports. Standard reports are provided for the most<br />
common administration tasks.<br />
The standard reports can be grouped by their use:<br />
Reports produced by the Helpdesk to help with troubleshooting functional problems<br />
Detailed authentication report<br />
User authentication history report<br />
Detailed Digipass registration report<br />
Detailed activity summary report<br />
Detailed Signature Validation report<br />
Detailed Provisioning report<br />
Signature Validation history report<br />
Reports produced by System administrators to help with troubleshooting system problems<br />
Failed Operations summary report<br />
Succeeded Operations summary report<br />
Reports produced by Administrators for Accounting information<br />
Authentication activity by user report<br />
Authentication activity by client report<br />
Provisioning activity by user report<br />
Provisioning activity by client report<br />
Transaction Signing Activity by User Application report<br />
Transaction Signing Activity by Client report<br />
Reports produced by Administrators for System auditing information<br />
Administration activity summary report<br />
Digipass availability by type report<br />
Digipass deployment trend report<br />
Digipass deployment by type report<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 125
11.4 Custom Reports<br />
Authentication trend report<br />
Transaction Signing Activity Trend<br />
Provisioning activity trend report<br />
Account lock trend report<br />
Digipass assignment activity summary report<br />
Reporting<br />
If there is not a standard report that meets your requirements, you can create a custom report using the Report<br />
Definition Wizard on the <strong>Identikey</strong> <strong>Server</strong> Web Administration application.<br />
A custom report can be created based on one of the available report types. Variables such as the subject of the<br />
report, and selection criteria can be specified to create the report you require.<br />
11.5 Report Generation Process<br />
Report generation relies on a number of components. An SQL query must be defined to retrieve the data that is<br />
required for the report. A report type must be selected from the list available. The result of the SQL query and the<br />
report type are then combined into an XML report. The XML report and the report format template are combined<br />
to produce the finished report in the required format.<br />
Image 37: Report Generation Process<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 126
11.6 Report Usage and Change Permissions<br />
Reporting<br />
Each report definition has an owner. The owner is usually the Administrator that created the report, but ownership<br />
can be transferred to another Administrator in the same Domain.<br />
Permissions are associated with each report that control:<br />
Who can run the report. Use can be restricted to the report owner, or it can be granted to other<br />
administrators.<br />
Who can change the report definitions. The ability to change the report format and details can be restricted to<br />
the report owner, or it can be granted to other administrators.<br />
Who can view the report.<br />
11.6.1 Usage permissions<br />
There are three types of usage permissions:<br />
11.6.2 Change Permissions<br />
Private – only the owner can view and run the report.<br />
Public – all administrators in all domains can view and run the report.<br />
Domain – the report can be run and viewed only by administrators that belong to the domain where the report<br />
was defined.<br />
There are three types of change permissions:<br />
Private – only the owner can change the report.<br />
Public – all administrators in all domains can change the report.<br />
Domain – the report can be changed only by administrators that belong to the domain where the report was<br />
defined.<br />
11.6.3 Permissions for standard reports<br />
The standard reports have 'private' permissions relating to changing the reports, and 'public' permissions relating<br />
to running and viewing the reports.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 127
11.7 Making Data Available to Reports<br />
Reporting<br />
When you are using data to create reports it makes sense to consider the way in which your data is stored and<br />
archived. The reports you can run use the audit data and the Data Store.<br />
An issue arises when you have more than one <strong>Identikey</strong> <strong>Server</strong> in your system. Audit messages can be stored on<br />
a database or in local text files. The database storage option can be local or centralised; text files are local. A<br />
report can only be run on one source of audit data, so if there is more than one <strong>Identikey</strong> <strong>Server</strong> you have the<br />
following options to enable reports to run on all the audit data:<br />
Online Centralized Database.<br />
Have a centralized Audit database. All <strong>Identikey</strong> <strong>Server</strong>s write to this database all the time. All reports can be run<br />
against this database all the time. If the centralized database is used it must be configured to be fast enough and<br />
big enough to cope with the load of Audit data.<br />
Offline Centralized Database<br />
Write the Audit data locally but periodically load the local data to a centralized Audit database. Each <strong>Identikey</strong><br />
<strong>Server</strong> must be configured to read the Audit data from the centralized database. Reports will only contain data up<br />
to the last load to the centralized Audit Database.<br />
Offline Centralized Database with Reporting <strong>Server</strong><br />
Write the Audit data locally but periodically load the local data to a centralized Audit database. Each <strong>Identikey</strong><br />
<strong>Server</strong> must be configured to read the Audit data from the local Audit data source. A reporting server can be<br />
installed that is configured to read its data from the centralized Audit database.<br />
Reports that need to use up to the minute data can be run on the server that retrieves its data locally. An example<br />
of this would be a user activity report for troubleshooting.<br />
Reports that need to use global data can be run on the reporting server. Reports will only contain data up to the<br />
last load to the centralized Audit Database.<br />
No Centralized Audit Data<br />
Configure each <strong>Identikey</strong> <strong>Server</strong> to retrieve Audit report data locally.<br />
An option to Upload Audit Data is available in the Configuration Wizard. This will allow you to configure <strong>Identikey</strong><br />
<strong>Server</strong> to upload local Audit Data to a centralized Audit Database.<br />
11.7.2 Archiving Strategy<br />
If you are running reports that will require data which is spread out over a long period of time, the reports will take<br />
a long time to run as the volume of data gets bigger. The best way of dealing with this growth is to archive the<br />
data. It is best to develop a good archiving strategy when your system is being implemented. Consider the kind of<br />
data you will want to report on, and the length of time you would like data to be available before being archived.<br />
Remember, archived data cannot be reported upon.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 128
12 <strong>Identikey</strong> Data Store<br />
12.1 Active Directory<br />
12.1.1 What is Stored in Active Directory?<br />
The following information is stored in Active Directory:<br />
Digipass User accounts<br />
12.1.2 Schema Extensions<br />
Digipass and Digipass Application records<br />
<strong>Identikey</strong> Data Store<br />
Digipass configuration records (Policies, Components, Back-End <strong>Server</strong>s, Reports and Report Formats)<br />
<strong>Identikey</strong> <strong>Server</strong> Configuration information<br />
User attributes – vasco-UserExt class<br />
Extra VASCO attributes are added to an Active Directory User record via an 'auxiliary class' vasco-UserExt on the<br />
User class.<br />
Digipass and Digipass Application records<br />
The vasco-DPToken class is used to store Digipass attributes. It is also a container, in which vasco-DPApplication<br />
records for that Digipass are stored.<br />
Upon assignment to a User, the Digipass record is stored in the same location as the User.<br />
Policies, Components and Back-End <strong>Server</strong>s<br />
Policy, Component, Back-End <strong>Server</strong>, Report and Report Format records are stored in vasco-Policy, vasco-<br />
Component, vasco-BackEnd<strong>Server</strong>, vasco-Report and vasco-ReportFormat objects respectively. They are located in<br />
a single “Digipass-Configuration” container in a single Domain.<br />
12.1.3 Digipass Records<br />
12.1.3.1 Location of Digipass Records<br />
When a Digipass is assigned to a User, it is moved to the same location as the Digipass User account it is assigned<br />
to. This makes it easier to set up the permissions necessary for delegated administration.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 129
Note<br />
<strong>Identikey</strong> Data Store<br />
A Digipass record will not automatically be moved when the User account to which it is assigned<br />
is moved to another location. When moving User accounts within Active Directory, ensure that<br />
the records of any assigned Digipass are manually moved to the same location.<br />
Unassigned Digipass records may be stored in various places in the data store:<br />
Digipass Pool<br />
A container called Digipass-Pool is created during installation. This is intended as a general store for unassigned<br />
Digipass.<br />
Organizational Units<br />
If an Organizational Unit structure is used in the data store, Digipass can be loaded or moved either into the exact<br />
Organizational Units where the User accounts to which they will be assigned are located, or into a few key<br />
Organizational Units in the hierarchy where they may be assigned to Users in lower level Organizational Units.<br />
Users Container<br />
When Active Directory is used as the data store, Digipass can be loaded into the Users container so they are<br />
available for Users in that container. However, it is not recommended to use the Users container for either User<br />
accounts or Digipass.<br />
When looking for an available Digipass to assign to a User, the <strong>Identikey</strong> <strong>Server</strong> will first look in the same<br />
Organizational Unit as the specific User account. The Search Upwards in Organizational Unit hierarchy option,<br />
when enabled, allows the <strong>Identikey</strong> <strong>Server</strong> to search in parent Organizational Units and the Digipass Pool<br />
container. This option may be set at the Policy level for system searches (eg. Auto-Assignment and Self-<br />
Assignment) or at the time of the search for manual assignment.<br />
Note<br />
The <strong>Identikey</strong> <strong>Server</strong> will always find or assign the closest available Digipass record to the<br />
selected User record(s).<br />
12.1.3.2 Delegated Administration in Active Directory<br />
If the assignment is manual (performed by an administrator), it will only find and successfully assign Digipass from<br />
locations where the administrator has the correct permissions. The administrator must have read permission for<br />
Digipass objects in the location to find a Digipass record, and if it needs to be moved to the User's location, they<br />
must have delete permission for Digipass objects to successfully assign the Digipass. If the administrator has<br />
sufficient permissions to view a Digipass record but not to assign it, the assignment will fail.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 130
Table 5: Summary of Digipass Record Location Options<br />
Record Location Pros Cons<br />
Digipass Pool Digipass are available to be assigned to all<br />
Users, regardless of the Organizational Unit<br />
structure.<br />
Only administrators with access to the Digipass<br />
Pool may view or modify records for unassigned<br />
Digipass. This also means that only those<br />
administrators may manually assign Digipass.<br />
Organizational Unit Digipass may be portioned out to various<br />
Organizational Units. This is particularly useful<br />
where a company is contracted to provide<br />
authentication services to multiple companies,<br />
or where various departments have different<br />
Digipass quota.<br />
Users Container Digipass can be assigned to any User in the<br />
Users container.<br />
<strong>Identikey</strong> Data Store<br />
An extra permission must be assigned to all<br />
administrators who should be able to assign<br />
Digipass (if they are not Domain Admins). It is<br />
not possible to strictly subdivide the unassigned<br />
Digipass among the Organizational Units<br />
according to quotas.<br />
If an Organizational Unit runs out of Digipass to<br />
assign its Users, more Digipass records must be<br />
manually moved to the right location.<br />
Digipass in the Users container are only<br />
available to User accounts stored there.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 131
12.1.3.3 Typical Digipass Location Models<br />
Digipass Pool<br />
<strong>Identikey</strong> Data Store<br />
A centralised point of access and importation can be implemented by using the Digipass Pool to hold unassigned<br />
Digipass records. This option requires less calculation and high-level administration, as Digipass records are all<br />
imported into one area and there is no need to manually move records or calculate the exact number of Digipass<br />
required for each Organizational Unit or group of Units. However, permissions will need to be set up to permit<br />
delegated administrators access to move the Digipass out of the container upon assignment.<br />
The Digipass Pool is treated as the Domain Root by the <strong>Identikey</strong> <strong>Server</strong>, as Digipass records may not be saved in<br />
the Domain Root.<br />
Image 38: Digipass Record Locations - Digipass Pool<br />
In the diagram above, the <strong>Identikey</strong> <strong>Server</strong> is shown searching upwards through the Organizational Unit structure<br />
for available Digipass to assign to a Digipass User in the Organizational Unit B1. Because no available Digipass are<br />
found in B1, it searches in B, then in the Digipass Pool.<br />
Administrator 1 needs delegated administrator permissions for the Organizational Unit B and its child<br />
Organizational Units. They must also have read and delete permissions for Digipass objects in the Digipass Pool<br />
container.<br />
Note<br />
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to<br />
function correctly.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 132
Parent Organizational Units<br />
<strong>Identikey</strong> Data Store<br />
Unassigned Digipass can be kept in key Organizational Units, and made available to their lower level Organizational<br />
Units. This requires a delegated administrator to have permissions not only for the Organizational Unit in which the<br />
User accounts are stored, but also read, write and delete permissions for Digipass objects in the Organizational<br />
Unit in which the Digipass are stored.<br />
Image 39: Digipass Record Locations - Parent Organizational Unit<br />
In the diagram above, the <strong>Identikey</strong> <strong>Server</strong> can search in the parent Organizational Unit for available Digipass.<br />
The delegated administratration permissions can be set up in two basic ways:<br />
Administrator 1 has full admin permissions for Organizational Unit B and its child Organizational Units. She<br />
does not require any other permissions to assign Digipass from Organizational Unit B to a User in<br />
Organizational Unit B1.<br />
Administrator 2 has full admin permissions for Organizational Unit A2 only. He has read and delete permissions<br />
for Digipass objects in Organizational Unit A in order to assign Digipass from Organizational Unit A to a User in<br />
Organizational Unit A2.<br />
Note<br />
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to<br />
function correctly.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 133
Individual Organizational Units<br />
<strong>Identikey</strong> Data Store<br />
Digipass can be loaded or moved into each Organizational Unit where and when they are required. It is then easy<br />
to set up permissions for delegated administrators to assign them only within their scope of control. If all Digipass<br />
in the Organizational Unit are assigned, more Digipass will need to be moved in manually by a Domain Admin<br />
before they can be assigned by a delegated administrator.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 134
Image 40: Digipass Record Locations - Individual Organizational Units<br />
<strong>Identikey</strong> Data Store<br />
In the diagram above, unassigned Digipass are stored in the exact Organizational Units in which they will be<br />
assigned.<br />
Each delegated administrator only requires permissions within their specific Organizational Unit(s).<br />
Note<br />
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for<br />
this model.<br />
Combination of models<br />
Digipass may be stored in the Digipass Pool as well as some or all Organizational Units. If no unassigned Digipass<br />
records are found in the Organizational Unit, and the Search Upwards in Organization Unit hierarchy option is<br />
enabled, the <strong>Identikey</strong> <strong>Server</strong> will search upwards to the Domain Root and search in the Digipass Pool for an<br />
available, unassigned Digipass record.<br />
12.1.4 Permissions Needed by the <strong>Identikey</strong> <strong>Server</strong><br />
The installation process will ensure that the <strong>Identikey</strong> <strong>Server</strong> has sufficient permissions. This is achieved by<br />
assigning permissions in the domain to the in-built “RAS and IAS <strong>Server</strong>s” group. It is necessary to make sure that<br />
the <strong>Identikey</strong> <strong>Server</strong> is added to that group.<br />
12.1.5 Administrative Permissions<br />
Administrative permissions for <strong>Identikey</strong> <strong>Server</strong> administrators are controlled using Active Directory security<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 135
<strong>Identikey</strong> Data Store<br />
properties. See the Permissions Needed by Administrators topic in the Administrator Reference for more<br />
information.<br />
Domain Administrators may view and edit all Digipass and Digipass User information in their domain, plus<br />
Digipass Configuration information if the Digipass Configuration Container is located in their domain. No<br />
permissions setup is required for them.<br />
Delegated Administrators may view and edit all Digipass and Digipass User information within their<br />
administrative scope of control. It is necessary to grant them full control, create and delete permissions over the<br />
Digipass and Digipass Application objects within their scope.<br />
Reduced Rights Administrators may perform a subset of the administration tasks. 'Property sets' are defined<br />
with the directory which can be used to enable or limit them in various Digipass administration tasks (eg. Access to<br />
the Digipass blob).<br />
12.1.6 Active Directory Command Line Utility<br />
This utility has to perform several tasks that are needed at various times during installation and upgrade if Active<br />
Directory is selected, or afterwards for maintenance. Some of the commands are run automatically by the<br />
installation program, while others are run manually. The commands that are run automatically can be run manually<br />
also, for example to troubleshoot why the installation is not succeeding.<br />
Table 6: DPADadmin tasks<br />
Command Description<br />
addschema Extend the Active Directory schema.<br />
checkschema Check that the schema extensions are all present.<br />
setupdomain Sets up the Digipass Configuration Container in the specified domain.<br />
setupaccess Assign permissions to a Windows group including:<br />
Full read access to everything in the domain<br />
Full control over vasco-DPToken objects<br />
Full control over vasco-DPApplication objects<br />
Ability to create and delete vasco-DPToken objects<br />
Full write access to extension attributes on user objects<br />
This command can optionally be used to also add a machine to the group.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 136
12.1.7 Active Directory Replication<br />
<strong>Identikey</strong> Data Store<br />
For more details of Active Directory Replication see Active Directory Replication Issues in the Administration<br />
Reference <strong>Guide</strong>.<br />
12.2 ODBC Database<br />
You may use the embedded PostgreSQL database supplied with <strong>Identikey</strong> <strong>Server</strong>, or another ODBC-compliant<br />
database.<br />
12.2.1 What is Stored in the Data Store?<br />
The following information is stored in the data store:<br />
Digipass User accounts<br />
Digipass and Digipass Application records<br />
Digipass configuration records (Policies, Components, Back-End <strong>Server</strong>s, Reports and Report Formats)<br />
<strong>Identikey</strong> <strong>Server</strong> Configuration information<br />
12.2.2 Domains and Organizational Units<br />
Image 41: Domains and Organizational Units<br />
Domains and Organizational Units are included in the ODBC database in a way that mirrors the data structure used<br />
by Active Directory.<br />
Organizational Units are designed to hold User accounts and Digipass records. They allow grouping of Users<br />
according to department, job function, or other criteria. They also allow Digipass to be allocated for Auto-<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 137
<strong>Identikey</strong> Data Store<br />
Assignment to single or multiple groups of Users. Both Domains and Organizational Units can be used to limit<br />
administrators to a group of Users and/or Digipass.<br />
12.2.3 Location of Digipass Records<br />
When a Digipass is assigned to a User, it is moved to the same Organizational Unit as the Digipass User account to<br />
which it is assigned.<br />
Note<br />
When a User account is moved to an Organizational Unit, all Digipass records assigned to it will<br />
also be moved.<br />
A Digipass record assigned to a User cannot be moved - the User account must be moved.<br />
Unassigned Digipass records may be allocated to various places in the Organizational Unit structure:<br />
Master Domain<br />
During installation, a default domain is created. Digipass are imported to the Master Domain, and may then be<br />
moved to other domains and Organizational Units.<br />
Organizational Units<br />
If an Organizational Unit structure is used in the database, Digipass can be moved either into the exact<br />
Organizational Units where the User accounts to which they will be assigned are located, or into a few key<br />
Organizational Units in the hierarchy where they may be assigned to Users in lower level Organizational Units.<br />
When looking for an available Digipass to assign to a User, the <strong>Identikey</strong> <strong>Server</strong> will first look in the same<br />
Organizational Unit as the specific User account, if the User account belongs to an Organizational Unit. The Search<br />
Upwards in Organizational Unit hierarchy option, when enabled, allows the <strong>Identikey</strong> <strong>Server</strong> to search in parent<br />
Organizational Units and the Digipass Pool container. This option may be set at the Policy level for system searches<br />
(eg. Auto-Assignment and Self-Assignment) or at the time of the search for manual assignment.<br />
Note<br />
The <strong>Identikey</strong> <strong>Server</strong> will always find or assign the closest available Digipass record to the<br />
selected User record(s).<br />
If the User account being assigned a Digipass does not belong to an Organizational Unit, the <strong>Identikey</strong> <strong>Server</strong> will<br />
look for an available Digipass in the domain which does not belong to an Organizational Unit.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 138
12.2.3.2 Typical Digipass Location Models<br />
Domain Root<br />
Digipass records may be stored in the Domain Root while unassigned.<br />
<strong>Identikey</strong> Data Store<br />
This option allows a centralised point of access for assignment of Digipass. It also requires less calculation and<br />
high-level administration - Digipass records are all stored in one area and there is no need to manually move<br />
records or calculate the exact number of Digipass required for each Organizational Unit or group of Units.<br />
Administrators must belong to the Domain only (not an Organizational Unit) to assign Digipass from the Domain<br />
Root.<br />
Image 42: Digipass Record Locations – Domain Root<br />
In the diagram above, the <strong>Identikey</strong> <strong>Server</strong> searches upwards through the Organizational Unit structure for available<br />
Digipass to assign to a Digipass User in the Organizational Unit B1. Because no available Digipass are found in B1,<br />
it searches in B, then in the Domain root.<br />
The administrator account must be located in the domain root (no Organizational Unit) in order for this model to<br />
work successfully.<br />
Note<br />
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to<br />
function correctly.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 139
<strong>Identikey</strong> Data Store<br />
This option is simplified if an Organizational Unit structure is not used in the database. User accounts and Digipass<br />
records may all be stored in the Master Domain. The Search Upwards in Organizational Unit hierarchy option<br />
does not need to be enabled in this case.<br />
Parent Organizational Units<br />
Unassigned Digipass can be kept in key Organizational Units, and made available to their lower level Organizational<br />
Units.<br />
Image 43: Digipass Record Location – Parent Organizational Unit<br />
In the diagram above, the <strong>Identikey</strong> <strong>Server</strong> can search in the parent Organizational Unit for available Digipass.<br />
Administrators will need to belong to the parent Organizational Unit.<br />
Note<br />
The Search Upwards in Organizational Unit hierarchy option must be enabled for this model to<br />
function correctly.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 140
Individual Organizational Units<br />
<strong>Identikey</strong> Data Store<br />
Digipass can be loaded or moved into each Organizational Unit where and when they are required. If all Digipass in<br />
the Organizational Unit are assigned, more Digipass will need to be moved in manually by a Domain Admin before<br />
they can be assigned.<br />
Image 44: Digipass Record Location s – Individual Organizational Units<br />
In the diagram above, unassigned Digipass are stored in the exact Organizational Units in which they will be<br />
assigned.<br />
Administrator accounts belonging to the Organizational Units A1 and A2 have administration privileges in their own<br />
Organizational Unit only.<br />
Note<br />
The Search Upwards in Organizational Unit hierarchy option does not need to be enabled for<br />
this model.<br />
Combination of models<br />
Digipass may be stored in the Master Domain as well as some or all Organizational Units. If no unassigned<br />
Digipass records are found in the Organizational Unit, and the Search Upwards in Organization Unit hierarchy<br />
option is enabled, the <strong>Identikey</strong> <strong>Server</strong> will search upwards to the Domain Root and search in the Digipass Pool for<br />
an available, unassigned Digipass record.<br />
12.2.4 Permissions Needed by the <strong>Identikey</strong> <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong> will require either:<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 141
a database administrator account for the database,<br />
ownership of the VASCO tables, or<br />
permissions to insert, remove, read and modify rows in VASCO tables.<br />
<strong>Identikey</strong> Data Store<br />
See the Administrator Reference for more information. This is set up automatically in the case of the embedded<br />
database option.<br />
12.2.5 Database Command Line Utility<br />
This utility has to perform several tasks that are needed at various times during installation and upgrade, or<br />
afterwards for maintenance. Some of the commands are run automatically by the installation program, while others<br />
are run manually. The commands that are run automatically can be run manually also, for example to troubleshoot<br />
why the installation is not succeeding.<br />
Command Description<br />
addschema Modify the database structure to create the required VASCO tables.<br />
checkschema Check that the required database modifications and/or table name remappings have been<br />
completed.<br />
dropschema Remove all database schema modifications from the database.<br />
Table 7: DPDBadmin commands<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 142
12.2.6 Additional ODBC Databases<br />
<strong>Identikey</strong> Data Store<br />
A synchronized backup database may be set up for the <strong>Identikey</strong> <strong>Server</strong>. This helps to ensure continuous service if<br />
the main database fails. The synchronization can be a shadow database, a mirror or a replicated copy.<br />
The required synchronization must be set up according to the instructions provided by the database vendor. It is<br />
strongly recommended to minimize the synchronization delay.<br />
Once the database and any synchronization is set up, create a Data Source Name for the new database and add it<br />
to the <strong>Identikey</strong> <strong>Server</strong> Configuration GUI.<br />
Image 45: Additional ODBC databases<br />
See the Database Connection Handling topic in the Administrator Reference <strong>Guide</strong> for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 143
12.2.7 Multiple <strong>Identikey</strong> <strong>Server</strong>s<br />
If more than one <strong>Identikey</strong> <strong>Server</strong> is installed on the system, some additional setup may be required.<br />
Multiple <strong>Identikey</strong> <strong>Server</strong>s Using Same Database<br />
<strong>Identikey</strong> Data Store<br />
If more than one <strong>Identikey</strong> <strong>Server</strong> is using the one ODBC database, no additional setup steps are required. A<br />
backup database should be considered.<br />
Image 46: Multiple <strong>Identikey</strong> <strong>Server</strong> Using Single Database<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 144
12.2.8 Replication<br />
<strong>Identikey</strong> Data Store<br />
When multiple <strong>Identikey</strong> <strong>Server</strong>s are in use each with their own database, they can be configured to replicate data<br />
changes between them, to keep all database synchronized.<br />
12.2.8.1 Common Scenarios<br />
Primary and Backup <strong>Identikey</strong> <strong>Server</strong>s<br />
The most common, and most basic, replication setup is used when a company has two <strong>Identikey</strong> <strong>Server</strong>s – one<br />
primary, to which all authentication requests are customarily sent, and a backup <strong>Identikey</strong> <strong>Server</strong> for use when the<br />
primary server is busy or unavailable. Replication is usually set to occur very frequently.<br />
Image 47: Replication between a Primary and Backup <strong>Identikey</strong> <strong>Server</strong><br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 145
12.2.8.2 Other Scenarios<br />
Primary, Backup and Disaster Recovery <strong>Identikey</strong> <strong>Server</strong>s<br />
<strong>Identikey</strong> Data Store<br />
This scenario is often used when a company requires an offsite disaster recovery <strong>Identikey</strong> <strong>Server</strong> and database.<br />
Image 48: Replication between Primary, Backup, and Disaster Recovery in <strong>Identikey</strong> <strong>Server</strong><br />
Other replication scenarios may also be used. For example, a company may have three <strong>Identikey</strong> <strong>Server</strong>s, all<br />
replicating to each other. This may keep data up to date better than a simpler replication chain.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 146
Image 49: Replication between three <strong>Identikey</strong> <strong>Server</strong>s<br />
<strong>Identikey</strong> Data Store<br />
Or, a company might require two Primary <strong>Identikey</strong> <strong>Server</strong>s, each with a backup <strong>Identikey</strong> <strong>Server</strong>, and add in an<br />
extra replication link to speed up data communications:<br />
Image 50: Complex <strong>Identikey</strong> <strong>Server</strong> Replication Scenario<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 147
12.3 Sensitive Data Encryption<br />
<strong>Identikey</strong> Data Store<br />
Sensitive data is encrypted by the <strong>Identikey</strong> <strong>Server</strong> using an embedded key. If needed, this encryption may be<br />
strengthened by including a custom encryption key. See the Administrator Reference <strong>Guide</strong> for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 148
13 Licensing<br />
13.1 Overview<br />
Licensing<br />
VASCO products are licensed per Component record in the data store. The licensing relies upon a License Key<br />
which is checked when the <strong>Identikey</strong> <strong>Server</strong> starts. This License Key is tied to the location (IP address) where the<br />
<strong>Identikey</strong> <strong>Server</strong> is installed, and stored in the Component record for the <strong>Identikey</strong> <strong>Server</strong>. The <strong>Identikey</strong> <strong>Server</strong> will<br />
not authenticate a user without a correct License Key, except to permit administration. SOAP, RADIUS, and the<br />
Authorization, Signature Validation and Provisioning scenarios all require a License Key.<br />
Client modules – such as the IIS 6 Module or Citrix Web Interface – also require a License Key to be loaded into<br />
their Component record. The <strong>Identikey</strong> <strong>Server</strong>s to which they connect will otherwise reject all authentication<br />
requests from them.<br />
Evaluation License<br />
An evaluation license means that you can use its full functionality until the evaluation period runs out. At the end of<br />
this period, you will need to either uninstall the product or buy a permanent license. Contact your distributor or the<br />
appropriate VASCO Reseller representative to acquire the licences you will need. For your convenience, the<br />
evaluation serial number is embedded in the installation program. You will still need to obtain and load a license<br />
key.<br />
Client module licenses can also be evaluation (time-limited) licenses.<br />
13.2 Obtaining and Loading a License Key<br />
The <strong>Identikey</strong> <strong>Server</strong> Configuration Wizard will guide you through the process of requesting and loading a License<br />
Key. However, if for some reason it is not possible to complete the licensing at installation time, the Web<br />
Administration Interface can be used to obtain and load a License Key for a Component. This process must be<br />
completed for each <strong>Identikey</strong> <strong>Server</strong>, and requires an active internet connection to open the Manage <strong>Identikey</strong><br />
<strong>Server</strong>Page.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 149
14 Auditing and Tracing<br />
14.1 Audit System<br />
Auditing and Tracing<br />
The VASCO Audit System consists of a number of auditing modules which save audit messages to a specific<br />
format (eg. text file or database) and an Audit Viewer which can open, display and filter audit messages from<br />
various sources.<br />
Image 51: Audit System Overview<br />
Audit messages are primarily generated by the <strong>Identikey</strong> <strong>Server</strong>. They may be recorded by a number of different<br />
methods:<br />
Windows Event Log (to be viewed in the Event Log Viewer)<br />
Syslog (In Linux environments)<br />
Text file<br />
ODBC-compliant database<br />
Audit messages may also be passed directly to an Audit Viewer as a live feed.<br />
14.1.1 Configure Auditing Output<br />
Auditing output from the <strong>Identikey</strong> <strong>Server</strong> can be configured using the <strong>Identikey</strong> <strong>Server</strong> Configuration. See the<br />
Configuration section of the Administrator Reference for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 150
14.1.2 Audit Viewer<br />
Image 52: Audit Viewer<br />
Auditing and Tracing<br />
The Audit Viewer can retrieve messages from several different sources and display audit messages from each in<br />
separate windows. Audit messages may be filtered by message type, date and time, or the contents of specific<br />
fields.<br />
14.1.3 Starting the Audit Viewer<br />
Windows<br />
Use the Start menu (by default, Programs -> VASCO -> <strong>Identikey</strong> <strong>Server</strong> -> Audit Viewer) or go to the <strong>Identikey</strong><br />
<strong>Server</strong> installation/bin directory.<br />
Linux<br />
1. Navigate to the <strong>Identikey</strong> <strong>Server</strong> installation directory (by default, /opt/vasco/<strong>Identikey</strong>).<br />
2. Start the Audit Viewer by entering these commands:<br />
vds_chroot /bin/bash<br />
dpauditviewer<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 151
14.1.4 Audit message types<br />
Type Description<br />
Auditing and Tracing<br />
Error The message contains details about a system, configuration, licensing or some internal error. Errors do<br />
not include normal processing events such as failed logins.<br />
Warning Warning messages contain details about potential problems within the system. This could include details<br />
such as a failed connection attempt to a database<br />
Information Informational messages provide details about events within the system that need to be recorded but do<br />
not indicate errors or potential errors.<br />
Success Success messages contain details about processing events that were correctly processed. This may<br />
include successful authentications or successful administration commands.<br />
Failure Failure messages contain details about processing events that failed. This may include rejected<br />
authentications, or administration actions that failed.<br />
Table 8: Audit message types<br />
14.1.5 Active Directory Auditing<br />
14.2 Tracing<br />
Active Directory auditing may be enabled and configured to record access and modifications to Digipass-related<br />
data used by the <strong>Identikey</strong> <strong>Server</strong>. See the Active Directory Auditing topic in the Administrator Reference for<br />
more information.<br />
The level of tracing for the <strong>Identikey</strong> <strong>Server</strong> can be configured using the <strong>Identikey</strong> <strong>Server</strong> Configuration utility.<br />
Tracing messages will be recorded to a text file.<br />
See the Tracing section in the Administrator Reference for more information, and instructions on configuring<br />
tracing for the <strong>Identikey</strong> <strong>Server</strong>.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 152
15 Message Delivery Component<br />
15.1 What is the Message Delivery Component?<br />
Message Delivery Component<br />
The Message Delivery Component (MDC) interfaces with a gateway service to send a One Time Password to a<br />
User’s mobile phone. The MDC acts as a service, accepting messages from the <strong>Identikey</strong> <strong>Server</strong>, which are then<br />
forwarded to a text message gateway via the HTTP/HTTPS protocol.<br />
Since every gateway uses different submission parameters, a set of configuration values is required, which can be<br />
administered by the MDC Configuration GUI. See the Configuration section of the Administrator Reference for more<br />
information.<br />
15.2 Starting the Message Delivery Component<br />
Windows<br />
The MDC service can be started and stopped through the Windows Service Manager Console.<br />
Linux<br />
To start the MDC daemon:<br />
1. Enter the chroot environment:<br />
vds_chroot /bin/bash<br />
2. Navigate to usr/share/vasco/init.d<br />
3. Enter the command:<br />
./mdc start<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 153
16 User Self Management Web Site<br />
16.1 What is the User Self Management Web Site?<br />
User Self Management Web Site<br />
The User Self Management Web Site allows Users to perform functions which are unavailable during a usual login<br />
– either because the functionality is disabled within the <strong>Identikey</strong> <strong>Server</strong> configuration, or because CHAP or another<br />
protocol is in use which does not allow the functionality:<br />
User Registration and Auto-Assignment<br />
Self-Assignment<br />
Password Synchronization<br />
PIN Change<br />
Login Test<br />
The site can also be used to help Users get started with their Digipass while they are still in the office and help is<br />
available.<br />
Image 53: User Self Management Web Site<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 154
Important Note<br />
User Self Management Web Site<br />
The User Self Management Web Site is intended for RADIUS environments, and uses the RADIUS<br />
protocol to communicate with the <strong>Identikey</strong> <strong>Server</strong>. If the <strong>Identikey</strong> <strong>Server</strong> is not licensed for<br />
RADIUS, you will not be able to use the User Self Management Web Site.<br />
16.2 Customizing the User Self Management Web Site<br />
The User Self Management Web Site can be customized by modifying the pages provided with the installation. You<br />
may wish to:<br />
change the colors and graphics to match your corporate colors/logos.<br />
integrate the pages into a larger web site.<br />
translate or customize the text<br />
Any cosmetic part of the web pages may be modified. Completely new web pages may be used, provided that the<br />
correct form fields are posted to the CGI program, and query string variables are interpreted correctly. <strong>Server</strong><br />
scripting languages such as PHP or ASP, or any other way of generating HTML, can be used.<br />
See the Web Sites section of the Administrator Reference for more information.<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 155
Alphabetical Index<br />
Activation Code........................................................................................87<br />
Active Directory............................................................................................<br />
Active Directory User..........................................................................38<br />
Archiving Strategy..................................................................................128<br />
Audit...........................................................................................................<br />
Active Directory Auditing..................................................................152<br />
Audit System...................................................................................150<br />
Audit Viewer....................................................................................151<br />
Authentication..............................................................................................<br />
Local................................................................................................ 45<br />
Auto-Assignment.......................................................................43, 47, 154<br />
Back End Authentication - Novell e-Directory.............................................58<br />
Back-End Authentication.......................................................................... 64<br />
Back-End Authentication - Active Directory................................................57<br />
Back-End Protocol....................................................................................54<br />
Back-End <strong>Server</strong>..........................................................................................<br />
Back-End <strong>Server</strong> record.....................................................27, 129, 137<br />
Backup Virtual Digipass....................................................................27, 106<br />
Challenge................................................................................................47<br />
Challenge/Response...............................................................9, 64, 65, 103<br />
1-Step Challenge/Response...............................................................48<br />
2-Step Challenge/Response...............................................................48<br />
Non-time-based..............................................................................104<br />
Time-based.....................................................................................103<br />
Challenge/Response ................................................................................12<br />
CHAP.....................................................................................17-20, 63, 64<br />
Check Digit............................................................................................104<br />
Citrix Web Interface..................................................................................36<br />
Command-Line Administration..................................................................93<br />
Communicator.........................................................................................15<br />
Component..................................................................................................<br />
Component record.............................................................26, 129, 137<br />
Configuration...........................................................................................94<br />
Configuration Wizard................................................................................25<br />
Context Menu..........................................................................................92<br />
Index<br />
Custom..................................................................................................126<br />
Custom Reports.....................................................................................126<br />
Customize..............................................................................................155<br />
Data field...................................................................................................9<br />
Database Synchronization.......................................................................143<br />
Deferred Signature Validation....................................................................67<br />
Digipass..................................................................................8, 9, 47, 103<br />
Assign.............................................................................................. 98<br />
Digipass Application...................................................................... 9, 27<br />
Digipass Assignment......................................................................... 93<br />
Digipass Blob....................................................................................26<br />
Digipass for Web...............................................................................12<br />
Digipass PIN....................................................................................103<br />
Digipass record.....................................26, 92, 99, 101, 130, 137, 139<br />
Digipass Record Administration..........................................................93<br />
Hardware Digipass.............................................................................10<br />
Lookup..............................................................................................45<br />
Programming..................................................................................103<br />
Search..............................................................................................93<br />
Serial Number...................................................................................99<br />
<strong>Server</strong> PIN.......................................................................................106<br />
Software Digipass..............................................................................12<br />
Unlock Digipass...............................................................................102<br />
Digipass Application...................................................................................9<br />
Digipass Extension for Active Directory Users and Computers..................... 92<br />
Digipass for Mobile...................................................................................12<br />
Digipass for Web......................................................................................12<br />
Digipass TCL Command-Line Administration............................................. 24<br />
Digipass User...............................................................................................<br />
Account..............................26, 28, 37, 42, 92, 96, 100, 129, 137, 138<br />
Account Creation...............................................................................96<br />
Linked...............................................................................................46<br />
Digital Signature...............................................................................8, 9, 11<br />
Digital signatures.....................................................................................66<br />
Domain............................................................................................56, 138<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 156
Domain........................................................................................................<br />
Active Directory.................................................................................27<br />
Default Domain..................................................................................38<br />
ODBC............................................................................................... 97<br />
DUR........................................................................................................96<br />
Dynamic User Registration..................................................................43, 54<br />
EAP...................................................................................................18, 64<br />
EAP-TTLS................................................................................................18<br />
Encryption............................................................................................. 148<br />
Engine.....................................................................................................29<br />
Event ......................................................................................................67<br />
Event Based Signature..............................................................................67<br />
Event Value............................................................................................105<br />
Event-based...........................................................................................103<br />
Generate digital signatures.......................................................................66<br />
Grace Period......................................................................................47, 99<br />
Group Check......................................................................................41, 45<br />
Group Check................................................................................................<br />
Back-End..........................................................................................42<br />
Pass Back.........................................................................................41<br />
'Reject..............................................................................................42<br />
<strong>Identikey</strong> <strong>Server</strong> Configuration...................................................................25<br />
IIS...........................................................................................................23<br />
IIS Module Component Check...................................................................36<br />
Internet Information Services.....................................................................21<br />
Licensing...............................................................................................149<br />
Evaluation License...........................................................................149<br />
License Key...............................................................................26, 149<br />
Local Authentication...........................................................................42, 45<br />
Message Delivery Component.................................................................153<br />
MPPE......................................................................................................63<br />
MS-CHAP..........................................................................................63, 64<br />
MS-CHAP2........................................................................................63, 64<br />
MS-CHAPv1.......................................................................................17-19<br />
MS-CHAPv2.......................................................................................17-19<br />
Multi-Mode..........................................................................................9, 12<br />
Index<br />
Offline Delivery.........................................................................................72<br />
One Time Password.............................................................8, 9, 11, 12, 49<br />
Length............................................................................................104<br />
Online delivery.........................................................................................72<br />
Organizational Unit.................................................................................138<br />
Organizational Unit.......................................................................................<br />
Active Directory.................................................................................28<br />
ODBC............................................................................................... 97<br />
OTP.............................................................................................19, 20, 21<br />
OTP Request Site.....................................................................................50<br />
Outlook Web Access or............................................................................ 36<br />
PAP.............................................................................................17-20, 63<br />
Password.....................................................................................................<br />
Password Autolearn...............................................................56, 64, 97<br />
Password Replacement......................................................................54<br />
RADIUS.............................................................................................22<br />
Static password.........................................................20, 22, 23, 50, 54<br />
Stored Password Proxy......................................................................55<br />
Stored Static Password......................................................................55<br />
Windows.....................................................................................22, 23<br />
PEAP.......................................................................................................18<br />
PIN..............................................................................................................<br />
Digipass PIN..............................................................................11, 103<br />
Force PIN Change............................................................................102<br />
<strong>Server</strong> PIN.................................................................................47, 106<br />
Policy..............................................................................................45, 114<br />
Effective Settings.............................................................................115<br />
Inheritance......................................................................................114<br />
Policy record.....................................................................27, 129, 137<br />
Policy record.........................................................................................<br />
Pre-loaded................................................................................117<br />
Privileges...............................................................................................135<br />
Provisioning.......................................................................................71, 72<br />
RADIUS..............................................................................................17, 29<br />
Attributes....................................................................................17, 54<br />
CHAP................................................................................................29<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 157
Client................................................................................................36<br />
Default RADIUS Client..................................................................36<br />
MPPE................................................................................................29<br />
MS-CHAP..........................................................................................29<br />
MS-CHAP2........................................................................................29<br />
PAP..................................................................................................29<br />
<strong>Server</strong>.......................................................................17, 18, 19, 20, 22<br />
RADIUS Client Component Check..............................................................36<br />
Real Time Signature Validation..................................................................66<br />
Replication.....................................................................................145, 147<br />
Report Generation..................................................................................126<br />
Report Permissions................................................................................127<br />
Report Type...........................................................................................122<br />
Reporting...............................................................................................121<br />
Reset...........................................................................................................<br />
Reset Application.............................................................................101<br />
Reset Application Lock.....................................................................102<br />
Reset PIN........................................................................................102<br />
Response Only.............................................................................9, 12, 103<br />
Scenario..................................................................................................15<br />
SEAL.......................................................................................................15<br />
Self-Assignment............................................................ 43, 54, 64, 98, 154<br />
<strong>Server</strong> PIN...............................................................................................64<br />
Set..............................................................................................................<br />
Set Event Counter............................................................................102<br />
Index<br />
Set PIN........................................................................................... 102<br />
Sign transaction.......................................................................................66<br />
Simple Name Resolution...........................................................................37<br />
Smartcard................................................................................................12<br />
SOAP......................................................................................................28<br />
Software Digipass................................................................................8, 71<br />
Standard Reports...................................................................................125<br />
Stored Password Proxy.................................................................55, 64, 97<br />
Test Digipass Application........................................................................102<br />
Text message............................................................................................8<br />
Time .......................................................................................................67<br />
Time based signature...............................................................................67<br />
Time Shift..............................................................................................105<br />
Time Step........................................................................................67, 105<br />
Time-based...........................................................................................103<br />
Tracing..................................................................................................152<br />
User Self Management Web Site.....................................................154, 155<br />
Virtual Digipass.......................................................................8, 47-49, 108<br />
Backup Virtual Digipass............................................... 13, 48, 108, 110<br />
Keyword............................................................................................50<br />
OTP..................................................................................................48<br />
Primary Virtual Digipass.....................................................................13<br />
Request Method................................................................................50<br />
Windows Name Resolution....................................................................... 37<br />
<strong>Identikey</strong> <strong>Server</strong> <strong>Product</strong> <strong>Guide</strong> 158