Identikey Server Product Guide

Product Guide

Disclaimer of Warranties and Limitations of Liabilities

The Product is provided on an 'as is' basis, without any other warranties, or conditions, express or implied, including but not limited to warranties of merchantable quality, merchantability of fitness for a particular purpose, or those arising by law, statute, usage of trade or course of dealing. The entire risk as to the results and performance of the product is assumed by you. Neither we nor our dealers or suppliers shall have any liability to you or any other person or entity for any indirect, incidental, special or consequential damages whatsoever, including but not limited to loss of revenue or profit, lost or damaged data of other commercial or economic loss, even if we have been advised of the possibility of such damages or they are foreseeable; or for claims by a third party. Our maximum aggregate liability to you, and that of our dealers and suppliers shall not exceed the amount paid by you for the Product. The limitations in this section shall apply whether or not the alleged breach or default is a breach of a fundamental condition or term, or a fundamental breach. Some states/countries do not allow the exclusion or limitation or liability for consequential or incidental damages so the above limitation may not apply to you.

Copyright

Copyright © 2009 VASCO Data Security, Inc., VASCO Data Security International GmbH. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of VASCO Data Security Inc.

RADIUS Documentation Disclaimer

The RADIUS documentation featured in this manual is focused on supplying required information pertaining to the RADIUS server and its operation in the Identikey Server environment. It is recommended that further information be gathered from your NAS/RAS vendor for information on the use of RADIUS.

Trademarks

VASCO®, Vacman®, IDENTIKEY®, aXs GUARD™, DIGIPASS®, and ® are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries.

Table of Contents

1

Overview... 8

1.1 What is Identikey Server?... 8

1.2 What is a Digipass?... 8

1.3 Types of Digipass... 9

1.4 Structure of Identikey Server... 14

1.5 Identikey Server in a RADIUS Environment... 17

1.6 Identikey Server in a Web Environment... 21

1.7 Administration Components... 23

1.8 Identikey Server Data Model... 26

1.9 Integrating Your Systems With Identikey Server... 28

1.10 SOAP SSL... 30

1.11 Available Guides... 32

2

User Authentication Process... 34

2.1 Logging in with a Digipass... 34

2.2 Authentication Process Overview... 35

2.3 Identifying the Component Record... 36

2.4 Digipass User Account Lookup and Checks... 37

2.5 Local Authentication... 45

2.6 Back-End Authentication... 54

2.7 Authorization Profiles/Attributes... 62

2.8 Host Code Generation... 62

2.9 Supported RADIUS Password Protocols... 63

2.10 Unsupported by Identikey Server... 64

3

Signature Validation Process... 66

3.1 Signing a Transaction... 66

3.2 How Do I Generate a Signature?... 66

3.3 Time based signature... 67

3.4 Event Based Signature... 67

3.5 Static Signature... 68

3.6 Signature Verification Process... 68

3.7 Policy Settings... 70

4

Software Digipass Provisioning... 71

4.2 Provisioning Scenarios... 74

4.3 DP110 Provisioning Overview... 81

4.4 What are the steps in registration of a Software Digipass?... 85

4.5 What are the steps in activation?... 87

4.6 Reactivation ... 88

5

Administration Interfaces... 89

5.1 Data Administration... 89

5.2 System Administration... 94

5.3 What do I need to use?... 95

6

Digipass User Accounts... 96

6.1 Digipass User Account Creation... 96

6.2 Changes to Stored Static Password... 97

6.3 Administration Privileges... 97

7

Digipass... 98

7.1 Importing Digipass... 98

7.2 Assigning Digipass to Users... 98

7.3 Digipass Record Functions... 101

7.4 Digipass Programming... 103

7.5 Digipass Record Settings... 105

7.6 Virtual Digipass Implementation Considerations... 108

8

Client Components... 111

9

Server Components... 113

10 Policies... 114

11 Reporting... 121

11.5 Report Generation Process... 126

11.6 Report Usage and Change Permissions... 127

11.7 Making Data Available to Reports... 128

12 Identikey Data Store... 129

12.1 Active Directory... 129

12.2 ODBC Database... 137

12.3 Sensitive Data Encryption... 148

13 Licensing... 149

13.1 Overview... 149

13.2 Obtaining and Loading a License Key... 149

14 Auditing and Tracing... 150

14.1 Audit System... 150

14.2 Tracing... 152

15 Message Delivery Component... 153

15.1 What is the Message Delivery Component?... 153

15.2 Starting the Message Delivery Component... 153

16 User Self Management Web Site... 154

16.1 What is the User Self Management Web Site?... 154

Illustration Index

Image 10: Structure of Identikey Server...14

Image 11 : SSL handshake process...32

Image 12 : Login Methods...34

Image 13: Authentication Process Overview...35

Image 14: Name Resolution with Active Directory...39

Image 15: Name Resolution with ODBC database...40

Image 16 - Dynamic User Registration Process...44

Image 17: User Account Link...46

Image 18: Virtual Digipass Login...49

Image 19: Multiple Digipass Assignment...51

Image 20: The steps in Back-End Authentication for Novell eDirectory and ADAM...59

Image 21: Steps of Signature Verification Process ...68

Image 22: Steps of Provisioning...73

Image 23: Digipass for Mobile Scenario 1 process ...75

Image 24: Digipass for Web Scenario 1 Process ...77

Image 25: Digipass for Web Scenario 2 Process ...78

Image 26: Digipass for Web Scenario 3 Process ...80

Image 27: DP110 Scenario 1...82

Image 28: DP110 Scenario 2...84

Image 29: Steps of Software Digipass Registration...85

Image 30: Steps of Software Digipass Activation...87

Image 31: Self Assignment Process ...99

Image 32: Auto Assignment Process ...100

Image 33: Manual Assignment Process ...101

Image 35: Reporting Structure...121

Image 36: Report Grouping...124

Image 37: Report Generation Process ...126

Image 38: Digipass Record Locations - Digipass Pool...132

Image 39: Digipass Record Locations - Parent Organizational Unit...133

Image 40: Digipass Record Locations - Individual Organizational Units...135

Image 41: Domains and Organizational Units...137

Image 42: Digipass Record Locations – Domain Root...139

Image 43: Digipass Record Location – Parent Organizational Unit...140

Image 44: Digipass Record Location s – Individual Organizational Units...141

Image 45: Additional ODBC databases...143

Image 46: Multiple Identikey Server Using Single Database...144

Image 47: Replication between a Primary and Backup Identikey Server...145

Image 48: Replication between Primary, Backup, and Disaster Recovery in Identikey Server...146

Image 49: Replication between three Identikey Servers...147

Image 50: Complex Identikey Server Replication Scenario...147

Image 51: Audit System Overview...150

Image 52: Audit Viewer...151

1

Overview

1.1

What is Identikey Server?

Identikey Server is a server product designed to support the deployment, use and administration of VASCO Digipass technology. It can be easily integrated with existing applications using a Software Developer Kit (SDK). Identikey Server provides support for the following primary functions:

Digipass One Time Password Authentication Digipass Signature Validation

Software Digipass Provisioning Administration and Reporting Auditing

Identikey Server is designed to be easily usable with Web applications and has a Web-based Administration interface.

1.2

What is a Digipass?

A Digipass is a device for providing One Time Passwords and Digital Signatures to a User.

A Digipass may be provided to each person whom an organization wishes to be able to log into their system using a One Time Password (OTP). The User obtains an OTP from the Digipass to use instead of, or as well as, a static password when logging in.

In addition, a Digipass may be provided for the user to sign transaction data. The user enters key details of the transaction into their Digipass and receives a signature. They enter the signature into a transaction confirmation page in order to confirm that they authorize the transaction.

Virtual Digipass is a mechanism where an OTP is generated by the server and sent by text message to the User's mobile phone. In this case, a physical Digipass device is not needed.

A Software Digipass may be installed onto your computer, or onto a mobile device such as a Blackberry or Java-enabled mobile phone. It can be used to generate an OTP or a Signature in the same way as a physical Digipass device.

1.3

Types of Digipass

Each Digipass is programmed with at least one Digipass Application and a unique secret. The Digipass Application uses this secret when generating One Time Passwords and Signatures.

Each type of Digipass Application generates One Time Passwords or Signatures from different data, and in slightly different ways:

Response Only

Creates a One Time Password based on the current date and time or on the number of uses (events).

Challenge/Response

Creates a One Time Password (also referred to as a 'Response') based on a numerical challenge given on a login page. This may be either a challenge custom-created for the specific Digipass, or a randomly created challenge. The One Time Password may also be based on the date and time.

Digital Signature

Digital Signature Digipass Applications are typically used in online banking. The Digipass generates a unique code - referred to as a 'Digital Signature' - based on a number of transaction data fields entered, plus (optionally) the date and time or number of uses (events).

Multi-Mode

Multi-mode Digipass are Digipass that are capable of being used in all of the above modes. This setting is used mainly for Digipass for Web.

1.3.2

Hardware Digipass

Hardware Digipass are devices specifically designed for creation of One Time Passwords and Digital Signatures. Depending on the model supplied, they may be used for Response Only, Challenge/Response and Digital Signature methods.

The three basic types of hardware Digipass are:

Digipass without keypads

These are the simplest type of Digipass. They have a triggering mechanism - typically a button or action, such as pulling the Digipass open - which causes a One Time Password to be generated. They have only one Application, which is always Response Only.

Image 1: GO 3 Image 2: GO 5

Digipass with keypads

These are typically capable of supporting more than one Application, and can be programmed so that a PIN must be entered before a One Time Password or Digital Signature may be generated.

Image 4: DP 585 Image 5: DP 260

Smartcard reader Digipass

These provide two-factor authentication based on smartcard technology in a similar way to the above two types. The smartcard itself provides the 'secret' that is used to generate OTPs and Digital Signatures.

Image 7: DP 810 Image 8: DP 805

1.3.3

Software Digipass

Software Digipass may be installed onto a Blackberry, Java-enabled mobile phone or other mobile device. The User then accesses a Digipass application to obtain a One Time Password or Digital Signature. They typically support Response Only, Challenge/Response or Digital Signature Digipass Applications.

Distribution of Software Digipass is controlled by Identikey Server using Provisioning scenarios. See 4 Software

Digipass Provisioning for more information.

Digipass for Web

Digipass for Web is a Java applet that runs on your internet browser. Digipass for Web can generate One Time Passwords and Digital Signatures. Digipass for Web supports the Multi-Mode Application type.

Digipass for Mobile

Digipass for Mobile is a Java applet that will run on your Java enabled mobile phone or Blackberry. Digipass for Mobile can generate One Time Passwords and Digital Signatures.

1.3.4

Hardware/Software Digipass

The Digipass 110 is currently the only Digipass available which combines the security of a hardware Digipass with the portability of a software Digipass. It consists of a secure USB stick used with a Java applet on the User's

computer. It holds the cryptographic information used in generating One Time Passwords for the User.

Distribution of the Java applet used with the DP 110 is handled by Identikey Server in the same way as Software Digipass. See 4 Software Digipass Provisioning for more information.

Image 9: DP 110

1.3.5

Virtual Digipass

Virtual Digipass can be used instead of hardware Digipass tokens, or as a backup mechanism when a User has mislaid their hardware Digipass. Using Virtual Digipass means that a User may receive a One Time Password on their mobile phone via text message.

There are two forms of Virtual Digipass available:

Primary Virtual Digipass are treated by Identikey Server almost identically to hardware and software Digipass - a record of each Primary Virtual Digipass must be imported into the data store, and may then be assigned to a User automatically or manually. The User will typically log in with their User ID and static password, have a text message sent to their mobile phone, and then enter the One Time Password from the text message in the second stage of their login.

The Backup Virtual Digipass feature allows a User to request a One Time Password sent to their mobile phone if 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 be limited to 2 days' usage, after which they will again need to use their usual Digipass to log in.

1.4

Structure of Identikey Server

The diagram below shows the basic structure of an organization's existing applications integrated with Identikey Server.

1.4.1

Customer Web Applications

Identikey Server provides support for web applications through an SDK based on the standard SOAP protocol. These applications may cover operational tasks such as authentication and signature validation, provisioning of Software Digipass or administration of Identikey Server.

SOAP over HTTPS is supported, versions 1.1 and 1.2. 'Document Literal' binding is used. A variety of SOAP client SDKs have been tested.

1.4.2

Remote Access Clients

Identikey Server supports the RADIUS protocol (according to RFC 2865) for remote network access authentication, to the same level as VACMAN Middleware 3.0. Some applications are written using RADIUS as an authentication protocol, and these applications will also be supported.

The SEAL protocol is a proprietary VASCO protocol used by the VASCO authentication modules. At the time of writing this includes the Digipass Packs for Citrix Web Interface, Outlook Web Access and IIS Basic Authentication. Identikey Server supports these SEAL client applications to the same level as VACMAN Middleware 3.0.

1.4.3

Identikey Server

The Identikey Server is a Service which receives and processes requests from the various client components. It may refer to a Back-End System for a part of the processing tasks.

Identikey Server has a modular architecture incorporating the following key concepts:

1.4.3.1 Communicator Modules

For each protocol by which requests can be received, a Communicator module is present. Each Communicator can be enabled or disabled as preferred, subject to support in the license. The following Communicators are present:

SOAP (requires a license option) RADIUS (requires a license option) SEAL (does not require a license option)

1.4.3.2 Scenario Modules

For each major group of functionality in the Identikey Server, a Scenario module is present. Each Scenario can be enabled or disabled as preferred, subject to support in the license. The following Scenarios are present:

Authentication (requires a license option) Signature Validation (requires a license option)

Provisioning (requires a license option)

Administration (does not require a license option) Reporting (does not require a license option) Replication (does not require a license option) Administration (does not require a license option) Audit Scenarios (does not requrire a license option) Configuration (does not require a license option)

1.4.4

Back-End Systems

A Back-End System is used as an authority for user accounts and static passwords, before a user account is created in Identikey Server and the user starts to use a Digipass. In addition, for RADIUS it may be used to provide RADIUS attributes back to the RADIUS client, as Identikey Server does not provide RADIUS attribute support on its own.

See 2.6 Back-End Authentication for more information.

1.4.5

Database Server

Identikey Server uses Active Directory or an ODBC-compliant database to store administration and configuration data.

1.5

Identikey Server in a RADIUS Environment

Identikey Server can be used in a RADIUS environment in a number of ways, depending on your company's requirements.

In the following scenarios, a RADIUS Client may be a dial-up NAS (Network Access Server), firewall/VPN appliance, Wireless Access Point, or another device that uses the RADIUS protocol for user authentication. Some software applications can also use RADIUS for authentication, for example Microsoft Internet Security and Acceleration Server (ISA), and can therefore also act as RADIUS Clients.

In the RADIUS protocol, 'attributes' are used for authorization and configuration of the remote access session in many cases. Identikey Server is specialized in providing strong authentication using Digipass, but is not designed to provide authorization. If authorization attributes are required, a RADIUS server product is used in conjunction with Identikey Server.

1.5.1

Stand-alone: No RADIUS Attributes Required

In this scenario, Identikey Server is used on its own, without a RADIUS server.

Identikey Server can generally be used without a RADIUS server if: RADIUS attributes are not required

1.5.2

Proxy Target: RADIUS Server Acts as Proxy

In this scenario, a RADIUS server acts as a proxy for authentication, effectively delegating the authentication process to Identikey Server. The RADIUS server provides the authorization attributes after Identikey Server has accepted the user credentials.

A RADIUS server can forward authentication to Identikey Server if:

The RADIUS server supports the proxying of authentication while returning attributes itself

The RADIUS server can forward the authentication request using one of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2

The RADIUS server supports an Challenge response from Identikey Server, if required. The Access-Challenge mechanism is used for Access-Challenge/Response and Virtual Digipass, although it is still possible to use Virtual Digipass without that mechanism.

If the RADIUS server is capable, this scenario allows Identikey Server to operate in an environment that uses certificate-based EAP protocols such as PEAP and EAP-TTLS. To make this work, the RADIUS server decrypts the user credentials into a simpler protocol before forwarding the request to Identikey Server.

1.5.3

Intermediary: RADIUS Server as Back-End Server

In this scenario, Identikey Server will forward requests to a RADIUS server in order to retrieve authorization attributes, after validating the One Time Password. It is necessary to provide a static password to the RADIUS server to achieve this. Therefore, there are two methods of implementing this:

1.5.3.1 Log in with OTP Only

Using this method, the User only enters their OTP (including a PIN if used). Identikey Server has to learn the static password for the User, so that when the User gives the correct OTP, it can send the static password to the RADIUS server.

This method can be used if:

One of the supported password protocols is used: PAP, CHAP, MS-CHAPv1, MS-CHAPv2 The static passwords can be 'learnt' by Identikey Server

If PAP is used, Identikey Server has the ability to learn the static passwords automatically. The User has to perform at least one login with their static password – if the RADIUS server accepts the password, Identikey Server can learn it.

However, if one of the other password protocols is used, this process is not possible. In that case, there are a few other ways in which the passwords can be learnt, through administrative data entry or using the User Self-Management Web Site.

1.5.3.2 Log in with Password and OTP

Using this method, the User enters their static password and OTP at each login. Identikey Server validates the OTP and if correct, forwards the static password to the RADIUS server.

This method can be used if:

The PAP password protocol is used, because CHAP and MS-CHAP hash the password and OTP together inseparably

1.6

Identikey Server in a Web Environment

1.6.1

Soap Integration

Identikey Server has a SOAP module that can be used to integrate Identikey Server with web applications. The Identikey Server SOAP interface allows the following Identikey Server functions to be integrated into web applications:

User Authentication Signature validation

Software Digipass Provisioning Administration

Reporting

1.6.2

IIS Module

In an IIS Web environment, Identikey Server can also use a component that plugs into Internet Information Services (IIS) to intercept authentication requests. This component, the IIS Module, verifies the credentials with Identikey Server first. Normally this means verification of the One Time Password (OTP). If the OTP is valid, the static password is given back to IIS as if the user had entered it, and the normal web site authentication process completes the login.

To enable verification by Identikey Server it is necessary to provide a static password, typically the Windows password, to IIS. Therefore, there are two methods of implementing this:

1.6.3

Log in with OTP only

Using this method, the User only enters their OTP (including a PIN if used). Identikey Server has to learn the static password for the User, so that when the User gives the correct OTP, it can give the static password back to IIS.

Identikey Server has the ability to learn the static passwords automatically if they are Windows passwords. The User has to perform at least one login with their static password – if this password is validated by Windows, Identikey Server can learn it.

The same process can also be used if the static passwords are held in a RADIUS server – however, the Identikey Server license must have RADIUS support activated for this to be enabled.

This process is not possible if the static passwords are not Windows or RADIUS passwords. In that case, administrative entry is required for the passwords.

1.6.4

Log in with Password and OTP

Using this method, the User enters their static password and OTP at each login. Identikey Server validates the OTP and if correct, returns just the static password to IIS.

This method may be necessary when the static passwords are not Windows passwords, for example they may be Novell passwords. It also may be suitable if you do not want Identikey Server to store your users' Windows passwords (although they are strongly encrypted).

1.7

Administration Components

1.7.1

Web Administration

A web-based administration application is provided with Identikey Server to enable administrators to carry out the majority of administration functions for the system. The Web Administration package allows administrators to perform tasks such as:

Administer User accounts Administer Digipass

Define the organizational structure Manage Policies

Create and run reports Manage Client components

Manage and Configure the Identikey Server

The Web Administration application uses the Identikey Server's SOAP administration interface to manage data.

1.7.2

Digipass Extension for Active Directory Users and Computers

An extension to Active Directory Users and Computers is available. This extension allows administration of Digipass User accounts and Digipass records where Identikey Server uses Active Directory as its data store.

1.7.3

The Audit System

The Audit System tracks operations carried out by Identikey Server. Each operation generates audit messages that are written to either a text file or a database.

Audit information can be used to generate reports, for example, the number of failed authentications over a certain period. Audit information can also be used by Identikey Server system administrators to monitor system performance, or suspicious activity.

1.7.3.1 The Audit Viewer

System administrators can use the Audit Viewer program to view Audit information. It allows System administrators to filter the audit information to make it easier to view and understand. The Audit Viewer also allows you to view audit information from different sources.

Using the Audit Viewer information helps system administrators to troubleshoot effectively, and to keep track of significant events in the system.

1.7.4

Reporting

The Web Administration package contains a reporting module. This module contains the tools required to run a set of standard reports and to create and run custom reports.

Reports may be based on User account and Digipass data as well as audit data. Formatting templates can be used to convert the output into the preferred format, using XSLT.

1.7.5

Digipass TCL Command-Line Administration

An extension to TCL is used for command-line administration tasks. The full power of TCL scripting can be used in order to automate bulk or regular administration tasks. A stand-alone TCL interpreter is also provided so that this functionality can be used where there is no TCL environment present already.

The TCL extension uses the Identikey Server to manage the data store. It uses the SEAL protocol to communicate with the Identikey Server.

1.7.6

Identikey Server Configuration

The Identikey Server uses a local XML text file to store certain configuration settings. These can be managed using a graphical user interface program.

There is also a Configuration Wizard program available to carry out certain maintenance tasks such as changing the IP address of the server.

1.8

Identikey Server Data Model

Identikey Server can use either an ODBC database (including the embedded PostgreSQL database) or Active Directory as its data store. The data model will vary slightly between ODBC and Active Directory stores.

The following kinds of record are stored in the Identikey Server data store:

1.8.1

Digipass record

A Digipass record must exist in the data store for each Digipass in use. This record contains: Information about the Digipass (eg. serial number and model)

The names and programming parameters of Applications in the Digipass The status of various options (eg. Digipass lock)

Some of the information in this record is encrypted together in what is called the 'Digipass Blob'. There is one 'Blob' per Application.

1.8.2

Digipass User account record

Each User who will be logging in using Digipass authentication will require a Digipass User account. The Digipass User account record contains information needed by Identikey Server such as authentication settings. A Digipass must be assigned to a Digipass User account before it can be used for authentication.

Administrative privileges are assigned to Digipass User accounts and therefore a Digipass User account is needed for each administrator.

1.8.3

Component record

Component records are created to represent: Identikey Servers

Authentication, Signature and Provisioning client components Administration client components

They are used for the following main purposes:

For clients, to indicate that it is permitted to process a request from that client and to specify a Policy (see below) to be used

For RADIUS Clients, to hold the Shared Secret

To hold a License Key for Identikey Servers and IIS Modules

1.8.4

Policy record

Policies specify various settings that affect the request handling processes. Each request is handled according to a Policy that is identified by the applicable Component record.

There are many Policy settings including the following examples: Whether Local and/or Back-End authentication should be used Whether various automatic management features should be used The Digipass Application types required

Backup Virtual Digipass settings

1.8.5

Back-End Server record

A Back-End Server record is required when a RADIUS or LDAP server is to be used by Identikey Server for authentication. It is possible to create more than one Back-End Server record, for fail-over purposes. You can also allocate different Back-End Servers for different user domains.

1.8.6

Domain record

Domains form the basis for the Organizational Structure in an ODBC database. Where Identikey Server uses Active Directory as its data store, the standard Active Directory Domains are used instead.

Active Directory

Identikey Server operates within the pre-existing Active Directory domain and Organizational Unit structure. Each Digipass User and Digipass must belong to a domain in Active Directory.

User IDs must be unique within a domain, but may be repeated between domains.

While Digipass User account and Digipass records can belong to any domain, a single domain is identified during installation as the Digipass Configuration Domain. This domain is used to store the Component, Policy and Back-End Server records. It is also used as a default domain for user lookup, when no domain is specified.

ODBC Database

Domains perform the following functions: allow different user groups to be separated

provide the ability to limit administrator activities to the administrator's own domain (delegated administration) allocate unassigned Digipass records to different Domains, for example to mirror the geographic location of the devices

Each Digipass User and Digipass must belong to a domain. One domain is identified as the Master Domain – this will be the default domain when none is specified. In addition, administrators in the Master Domain can be given rights to access data in all domains, where other administrators are limited to data in their own domain.

be unique in the database.

1.8.7

Organizational Unit record

Organizational Units, like Domains, are handled differently depending on whether the Identikey Server uses Active Directory or an ODBC database as its data store.

Active Directory

Where Identikey Server uses Active Directory as its data store, the standard Active Directory Organizational Units are used instead.

Digipass User accounts and Digipass records are normally stored in Organizational Units or the Users container. A special container called Digipass-Pool is created during installation to hold unassigned Digipass, although they can be located in Organizational Units instead.

Administration duties may be assigned to administrators per Organizational Unit, in the same way that regular user administration is delegated at that level.

ODBC Database

Where Identikey Server uses an ODBC database as its data store, Organizational Units allow further compartmentalisation of Digipass User accounts, Digipass records and administration duties. Organizational Units are included to:

provide the ability to limit administrator activities to the administrator's own Organizational Unit (delegated administration)

allocate unassigned Digipass records to different Organizational Units, for example to mirror the geographic location of the devices

Digipass User accounts and Digipass records may belong to an Organizational Unit, but this is not mandatory.

1.9

Integrating Your Systems With Identikey Server

1.9.1

SOAP Interfaces

SOAP interfaces are provided to support the following functions: User Authentication

Signature Validation

Software Digipass Provisioning Administration

You need to acquire the SDK for SOAP for further information.

1.9.2

RADIUS

RADIUS support is present for authentication (Access-Requests) using PAP, CHAP, MS-CHAP and MS-CHAP2. MPPE keys are generated for MS-CHAP and MS-CHAP2.

If you have an existing RADIUS Server, Identikey Server can use it as a Back-End System in order to retrieve RADIUS attributes from it. Alternatively, you can use the RADIUS Server as an authority to permit dynamic creation of user accounts in Identikey Server and verification of static passwords.

1.9.3

Custom Back-End Integration

You can write your own plug-in Engine to attach Identikey Server to your own back end system. This would be used primarily as an authority to permit dynamic creation of user accounts in Identikey Server and for verification of static passwords.

Refer to the SDK Overview Guide for further information.

1.9.4

Back-End Integration

There are a number of systems that can be used as Back-Ends to Identikey Server. These back-ends can be used as an authority on authentication data.

The following back-ends can be used: Microsoft Active Directory Microsoft ADAM

Novell e-Directory

1.10

SOAP SSL

1.10.1

What is SSL?

SSL stands for Secure Sockets Layer, which is a cryptographic protocol that provides secure communications over the Internet for e-mail, web browsing and, in this case, connection of two web-based applications via SOAP. SSL is the method by which a client can obtain a secure connection to a SSL-enabled server. The SSL-enabled server can identify itself to the client in a trusted manner before any information is passed between the client and the SSL-enabled server.

1.10.2

Terms Used in SSL

Some of the terms used in describing the function of SSL are specific to SSL and cryptography. Listed below are some of the terms used in this chapter, and what they mean:

Handshake Procedure - The client machine and the SSL-enabled server establish a trusted and secure connection before any sensitive information is passed between them

Certificate - The certificate in this context is an encrypted file attached to a message.

Certificate Authority - a trusted third party used to issue the certificates. Each browser will have a list of trusted Certificate Authorities it can use to check against the signature on a certificate.

Public Key - A key used to encrypt and decrypt information that is known to the SSL-enabled server and clients that use it.

Private Key - A key known only to the SSL-enabled server that is used to decrypt information. Symmetrical Encryption - encryption that uses only one key to encrypt and decrypt information. Asymmetric Encryption - encryption that uses two keys to encrypt and decrypt information.

1.10.3

How Does SSL work?

1. A client initiates a connection using a handshake procedure. The client connects to an SSL-enabled server (the server), requesting a secure connection.

2. The server sends back an encrypted certificate which usually contains the server name, the Certificate Authority and the server's public key.

3. The client decrypts the certificate using the server's public key. The client checks the Certificate Authority against its browser's list of trusted Certificate Authorities.

4. The client then encrypts a random number using the server's public key and sends this back to the server. This will be the secret that the client and server use to encrypt information passed between them.

5. The server then decrypts the random number using the private key. The nature of the public and private keys is that information encrypted with the public key can only be decrypted by the private key.

6. Information encrypted using the generated secret is passed between the client and server. If any part of the handshake procedure fails the whole handshake procedure will fail.

1.10.4

SSL, SOAP and Identikey Server

If you want to write SOAP interfaces for Identikey Server, the server side of SSL is mandatory. The SOAP client must utilize SSL to verify the server when attempting to connect.

When setting up the SOAP Communication Protocol on the Identikey Server Configuration application, you can specify whether the client certificate is required:

Never - the client certificate is never required. Optional - the client certificate is optional Required - The client certificate is required

Required - Signed Address Only - The Server must include its IP address in the certificate. The client will match this IP address against that of the server it is connecting to. If they don't match the handshake will fail. Similarly, the client certificate must include the IP address of the client. The Server will check the IP address from the client certificate against the client it is establishing a connection with, and the handshake will fail if the two IP addresses don't match.

The Identikey Server Configuration application provides a test SSL certificate. The test SSL certificate is time limited so it will expire after a period of time. When the test SSL certificate expires you can recreate it from the configuration application. Alternatively purchase an SSL certificate with a longer expiry period.

Image 11 : SSL handshake process

The Identikey Server Configuration application SOAP Communication protocol page also contains a check box labelled Re-Verify on Re-Negotiation. Check this box to force the connection between SOAP and the Identikey Server to be re-verified each time a connection is established. Please note that this may cause problems with performance and so should not be checked unless absolutely necessary.

The following Identikey Server guides are available:

Product Guide

The Product Guide will introduce you to the features and concepts of Identikey Server and the various options you have for using it.

Getting Started Guide

The Getting Started Guide will lead you through a standard setup and testing of key Identikey Server features.

Windows Installation Guide

Use this guide when planning and working through an installation of Identikey Server in a Windows environment.

Linux Installation Guide

Use this guide when planning and working through an installation of Identikey Server in a Linux environment.

Administrator Reference

In-depth information required for administration of Identikey Server. This includes references such as data attribute lists, backup and recovery and utility commands.

Performance and Deployment Guide

Contains information on common deployment models and performance statistics.

Help Files

Context-sensitive help accompanies the Administration Web Interface and Digipass Extension for Active Directory Users and Computers.

Identikey Server SDK Programmers Guide

2

User Authentication Process

2.1

Logging in with a Digipass

The diagram below shows a typical login process for the three basic login methods supported by Identikey Server.

2.2

Authentication Process Overview

Identikey Server Authenticates logins in two basic ways: Using information from its data store ('local' authentication)

Asking a Back-End system for verification of information ('back-end' authentication)

The exact authentication process used by Identikey Server will vary depending on settings in the applicable Policy and Digipass User account. The diagram below shows the basic process followed when authenticating a Digipass User login.

2.3

Identifying the Component Record

The component making an authentication request will be identified using:

Component Type – A name provided by the SOAP application, or a fixed name such as RADIUS Client, Citrix Web Interface, Outlook Web Access or Administration Program

Location – the source IP address of the request

The component lookup and verification processes are a little different according to the type of component, as outlined below.

2.3.1

RADIUS Client Component Check

For a RADIUS Client, the following component checks are made:

Component Record exists

A Component record for the RADIUS Client must exist, otherwise the request is discarded without responding: Type = RADIUS Client

Location = the source IP address of the request OR if there is no RADIUS client at the specified location, Location = default

Shared Secret is set

The Component record must have a Shared Secret value set, otherwise the request is discarded without responding.

Any RADIUS Client which does not have an explicit Component record will be handled using the “default” RADIUS Client Component if it exists.

2.3.2

IIS Module Component Check

For an IIS Module Component the following component checks are made:

Component Record exists

A Component record for the IIS module must exist, otherwise the request is discarded without responding: Type = IIS module

2.4

Digipass User Account Lookup and Checks

Identikey Server performs a number of checks before proceeding to local authentication.

2.4.1

User ID and Domain Resolution

In Identikey Server, Digipass User accounts are identified using a User ID and a Domain, not just a User ID. There are a few ways to do this:

2.4.1.1 Windows Name Resolution

In Windows environments, there are a few ways to provide these details when logging in: Using NT4-style domain qualification in front of the User ID: DOMAIN\userid

Using User-Principal-name (e.g. userid@domain)

With separate User ID and Domain fields (this is not possible using RADIUS)

When Digipass User accounts correspond to Windows user accounts, the Windows Name Resolution feature can be used to support these three login formats. With ODBC or an embedded database, it is optional whether to user Windows Name Resolution or not. However, if the Windows Name Resolution process is enabled and fails, the login is rejected. Therefore, a login with a User ID that does not correspond to a Windows user account will be rejected.

With this feature enabled, Windows is used to resolve the NT4-style and User-Principal-Name User ID formats. Windows Name Resolution is enabled using the Identikey Server Configuration program. Click the Configure Advanced Settings button on the ODBC Connection tab to get the Advanced Settings dialog; check the Use Windows User Name Resolution checkbox.

2.4.1.2 Simple Name Resolution

When Windows Name Resolution is not used, the following formats are available: Using a similar format to User-Principal-Name: user@domain

With separate User ID and Domain fields

If the user@domain format is used for the User ID, the Identikey Server will look for a Domain record with the name given after the @. If the Domain is found, the @domain part will be stripped from the User ID before the authentication process continues. If it is not found, the User ID will be left as user@domain, and no Domain will be identified. In that case, the Default Domain processing will be used, as described next.

2.4.1.3 Default Domain

Using either Windows or Simple Name Resolution, if none of the above formats are used, only the User ID is given, with no Domain qualification. It is still necessary to identify the Domain in order to look up the Digipass User account.

The Default Domain can be configured in the following ways:

In the Policy record, the Default Domain field can be set. If this is set, it will be used when no Domain has been identified by the Windows or Simple Name Resolution.

When the Policy has no Default Domain set, the Master Domain will be used.

2.4.1.4 Active Directory User Account

When Active Directory is used as the data store, Digipass User accounts are always attached to Active Directory User accounts. Therefore, if an authentication request is received for a User who does not have an account in Active Directory, the request is rejected.

2.4.1.5 Summary – Active Directory

The full process of User ID and Domain name resolution is illustrated in the following diagram, for the case where Active Directory is the data store:

2.4.1.6 Summary – ODBC Database

The full process of User ID and Domain name resolution is illustrated in the following diagram.

2.4.2

Windows Group Check (optional)

Specific Windows Groups can be selected for authentication by the Identikey Server when all Users are Windows accounts. This Windows Group Check feature might be used when:

Deploying Digipass in stages. Users are not required to log in using a Digipass until they are put into a Windows group. They can be put into the group in manageable stages.

Two-factor authentication is needed only for access to sensitive data, which has been granted to certain Users (for example, administrators). Only this group of people will require Digipass, and will be authenticated by the Identikey Server. Other Users will be authenticated by another authentication method.

Most Users will have Digipass and be permitted to log in to the system, but some Users should not be authenticated under any circumstances.

Authentication is needed for the live Audit Viewer connection to the Identikey Server, when using Active Directory as the data store. The Group Check can be used to limit which users are allowed to connect, for example to the Domain Admins group.

When the Group Check is active, Users who are in one of the defined groups go through the full authentication process. However, there are a few Group Check Modes that control the outcome for Users who are not in one of the groups. The Group Check Mode is defined in the Policy.

One or more Windows Group names must be defined in a Group List in the Policy. Group membership is checked within the User's own domain only, therefore these Groups must exist in each domain where there are Users who need to be included in a Group.

Important Note

When the Group Check is used, if the Group Check fails, the login will fail. This will occur for a user who is unknown to Windows.

The following Group Check Modes are available:

2.4.2.1 'Pass Back' Mode

The full name in the Policy property sheet for this mode is:

Pass requests for users not in listed groups back to host system

The Identikey Server does not handle authentication for Users who are not in one of the defined groups. These Users are handled by the host system (eg. IIS). In effect, this means that they do not need to have Digipass User accounts and they do not need to use a Digipass to log on. As soon as the Group Check indicates that the User is not to be handled, authentication processing stops and the 'not handled' result is returned.

This mode is suitable for staged deployment of Digipass and for the case where only certain Users need strong (Digipass) authentication.

2.4.2.2 'Reject' Mode

The full name in the Policy property sheet for this mode is:

Reject requests for users not in listed groups

The Identikey Server rejects authentication immediately for Users who are not in one of the defined groups. This mode is suitable for restricting which Users are permitted to log in.

2.4.2.3 'Back-End' Mode

The full name in the Policy property sheet for this mode is:

Use only Back-End Authentication for users not in listed groups

This mode can be used when Back-End Authentication is set up (see 2.6 Back-End Authentication ). The Identikey Server will just use Back-End Authentication for Users who are not in one of the defined groups. For example, if RADIUS Back-End Authentication is used, the job of authenticating Users not in the defined groups is delegated to the RADIUS server. No lookup will be carried out for the Digipass User account, and no further Local Authentication will be carried out.

Back-End Authentication will be used for the out-of-group Users even if the Policy setting for Back-End Authentication is set to None. In that case, the in-group Users would be authenticated only by Local Authentication, while the out-of-group Users would be authenticated only by Back-End Authentication. However, it is necessary to define the Back-End Protocol Policy setting.

This mode is suitable for staged deployment of Digipass and for the case where only certain Users need strong (Digipass) authentication.

2.4.3

Digipass User Account Lookup

The Identikey Server checks that the User attempting to log in has a Digipass User account in the Identikey Server data store. The User ID and Domain Resolution performed earlier determines the search criteria to look up the Digipass User account.

If a Digipass User account is found, the Disabled and Locked indicators are checked. If either is set to Yes, the authentication request is rejected immediately.

If no Digipass User account is found, then Policy settings will determine whether the Identikey Server continues processing or rejects the authentication request:

If Local Authentication is required, a Digipass User account must exist. It is only possible to proceed if the Dynamic User Registration feature is enabled. This is explained further below.

If Local Authentication is not required, authentication processing can proceed without a Digipass User account.

Digipass/Password or Digipass Only, Local Authentication is required.

2.4.4

Dynamic User Registration

Dynamic User Registration (DUR) allows Digipass User accounts to be created automatically when their credentials are validated by Back-End Authentication. The correct static password will be sufficient to permit a Digipass User account to be created. DUR saves the administrative work of manually creating or importing Digipass User accounts.

It is typically used in conjunction with:

the Digipass Auto-Assignment feature, which will assign the next available Digipass to the new Digipass User account as it is created, or

the Digipass Self-Assignment feature, which will allow the new User to assign a Digipass to their account as part of their login process

For more details on these Digipass assignment features, see 7 Digipass . In order to control the creation of new accounts, DUR can be used with:

the Windows Name Resolution feature (mandatory for Active Directory). This will prevent more than one Digipass User account being created for the same Windows User account, when they use different User ID formats to log in

the Windows Group Check feature, so that a staged creation of Digipass User accounts and assignment of Digipass is achieved

2.5

Local Authentication

Local Authentication is a term used to describe the Identikey Server authenticating a User based on information in its data store. Typically the Digipass One Time Password is required, but in other cases a static password may be sufficient.

The Local Authentication Policy setting indicates whether to perform Local Authentication, and if so, whether a static password is permitted. This setting is overridden by the same setting in the Digipass User account, unless that has the value Default. However, this setting in the Digipass User account would typically be used only for rare special case Users.

Using the Windows Group Check in Back-End Mode, this setting can be overridden. If a User is not in the list of groups, no Local Authentication will be performed.

The possible values for the Local Authentication setting are as follows:

None

No Local Authentication will take place.

Digipass/Password

A Digipass One Time Password or static password may be verified. As a general rule, until a User starts to use a Digipass, they may continue to authenticate with their static password.

Digipass Only

A Digipass One Time Password must be verified. Users without Digipass will not be able to log in. However, Self-Assignment is still possible, as an OTP is used as part of the process.

2.5.1

Digipass Lookup

The first step of Local Authentication is to search for Digipass records applicable to the login. Normally, this is a simple search for all Digipass assigned to the Digipass User account. However, there are exceptions:

2.5.1.1 No Digipass User Account

If there is no Digipass User account, no search will be done. This can occur if Dynamic User Registration is enabled.

2.5.1.2 Policy Restrictions

The Policy can specify restrictions on which types of Digipass and/or Digipass Applications may be used. Any combination of the following restrictions can be defined:

Application Names - a list of named Applications. Only Digipass that have one or more of the named Applications will be usable.

Application Type - either Response Only, Challenge/Response or Multi-Mode. Only Digipass with that Application Type will be usable, except Multi-Mode will match all application types.

Digipass Type - a list of models such as DPGO3, DP260. Only Digipass from the listed models will be usable. Therefore, it is possible that a Digipass User account that has a Digipass assigned is not able to use that Digipass to log in, when a certain Policy applies. They will be regarded as a User without a Digipass in that case. In a different kind of login, a different Policy may apply, with no restrictions. Then they would be treated as a User with a Digipass.

For example, a company has Go 3 Digipass (DPGO3) and Primary Virtual Digipass (DPVTL). The Outlook Web Access login permits both, so its Policy does not restrict Digipass Types. However the RADIUS VPN login requires the Go 3, so its Policy specifies Digipass Type = DPGO3.

2.5.1.3 Linked User Accounts

If a person has two Digipass User accounts, for example an administrative account and a 'normal user' account, the two accounts can be linked together. This provides the ability for the two accounts to share a Digipass. The Digipass is assigned to one of the accounts, then the other account is linked to it.

Image 17: User Account Link

When an authenticating Digipass user account is linked to another, the search for Digipass will be done for the

other account. In the example above, Digipass User account 2 is linked to Digipass User account 1. The Digipass is assigned to Digipass User account 1. When Digipass User account 1 logs in, the Digipass search is for that account. When Digipass User account 2 logs in however, the Digipass search is for Digipass User account 1.

Digipass User

account 1 Digipass User account 2 Digipass record

Attached to main User account

User Account Link

User can log into either account using the same

2.5.2

Authentication with Digipass

When the Digipass lookup returns at least one Digipass record, authentication processing requires a valid One Time Password to succeed, unless:

All Digipass found are within a Grace Period. This feature is described below. The User successfully requests a Challenge for Challenge/Response (see below). The User successfully requests a Virtual Digipass One Time Password (see below).

2.5.2.1 Server PIN

A Server PIN may be required in addition to the One Time Password. The Server PIN is entered during login with the OTP - instead of a Digipass PIN, which is entered into the Digipass device. In some cases a new Server PIN may need to be set. This gives the following permutations:

OTP - the normal login where a Server PIN is not required. PINOTP - the normal login where a Server PIN is required.

PINOTPnewpinnewpin - to change the Server PIN, the new PIN is put twice after the OTP.

OTPnewpinnewpin - to set the Server PIN on first use, when no initial PIN was programmed, the new PIN is put twice after the OTP. This is also necessary after an administrative PIN reset.

2.5.2.2 Grace Period

Each Digipass may be given a Grace Period when it is assigned to a Digipass User account. The Grace Period is there to allow some time before the User receives the Digipass and learns how to use it. The first time that the User logs in successfully with their Digipass, the Grace Period is ended. After that, they have to continue to use the Digipass. The Grace Period is time limited, so that the User is not able to delay too long before they start to use the Digipass.

The Grace Period can be set during manual administrative assignment of Digipass as well as during Auto-Assignment. However, it is not applicable to Self-Assignment, because the User must use the Digipass to complete the Self-Assignment process.

The Grace Period cannot apply when the Local Authentication setting is Digipass Only.

During the Grace Period, if OTP validation fails, the static password is checked. If the static password is valid, Local Authentication succeeds (but note that Back-End Authentication, if used, can subsequently still cause the overall login to fail).

The password is compared against the Digipass User account's password value. However, if the Digipass User account does not have a password set, the password has to be verified with Back-End Authentication. If there is no Back-End Authentication and no password in the Digipass User account, Grace Period password logins will not work.

If the passwords do not match and End Authentication is enabled, the password will be verified with Back-End Authentication.

2.5.2.3 Challenge Generation

There are two modes of Challenge generation for Challenge/Response:

2-Step Challenge/Response

This mode can be used for Web authentication, where Challenge/Response is supported. In this mode, the authentication process takes place in two steps.

First, the User requests a Challenge to be generated for them. The Policy defines how this request should be made, with the Request Method and Request Keyword settings (see below for more details on Request Methods). The Challenge is generated specifically for their Digipass, according to its programming.

Assuming that the request for the Challenge is accepted and a Challenge is returned, the User submits a second step login with the Response to the Challenge as their OTP. This second step goes through the whole authentication process again to verify the Response.

1-Step Challenge/Response

This mode is also possible for Web authentication, where Challenge/Response is supported. In this mode, the User sees only one logon step. This mode is suitable for time-based Challenge/Response, but is less secure for non-time based Challenge/Response. If an attacker manages to capture some valid Responses, they can repeatedly request new Challenges until one they know comes up again.

A random Challenge is requested automatically by the Web Application and presented to the User on the login page. A general-purpose Challenge is generated, without reference to any particular Digipass' programming. The User logs in with their Response to the Challenge as their OTP.

2.5.2.4 Virtual Digipass OTP Generation

Using Virtual Digipass, the authentication process takes place in two steps.

First, the User requests an OTP to be generated and delivered to them. The Policy defines how this request should be made, with the Request Method and Request Keyword settings (see below for more details on Request Methods). The OTP is generated specifically for their Digipass, according to its programming. It is sent to their mobile phone number, as recorded in the Digipass User account.

Backup Virtual Digipass has additional restrictions on usage, to keep the cost of text messages down. These are verified before an OTP will be generated. These restrictions are described in 7 Digipass .

Assuming that the request for the OTP is accepted and an OTP is generated and delivered successfully, the User submits a second step login with the OTP. This second step goes through the whole authentication process again to verify the OTP.

Image 18: Virtual Digipass Login

2.5.2.5 Requesting a Virtual Digipass OTP - User Perspective

There are three ways a User might request a One Time Password to be delivered with either a Primary or Backup Virtual Digipass:

2-step Login

Two login prompts are used to provide an easy-to-use login interface for Users with Virtual Digipass. The first prompt is used to request an OTP, the second to enter the received OTP. This can be used with applications which support 2-step logins eg. Citrix Web Interface, RADIUS with support for Challenge/Response.

Two 1-step Logins

The User must attempt two logins, the first of which will fail but will initiate the sending of an OTP to the User’s mobile. This is used when the 2-step login process is not supported - eg. RADIUS without support for Challenge/Response, Web HTTP Basic Authentication.

OTP Request Site

Alternatively - especially if a more user-friendly option than the previous is needed - Users can go to the OTP Request site when they need an OTP sent to their mobile phone, then login normally at the usual login screen.

2.5.2.6 Request Method and Keyword

For 2-Step Challenge/Response and Virtual Digipass, the method of requesting a Challenge or OTP respectively can be defined in the Policy. The methods for Primary Virtual Digipass and Backup Virtual Digipass are defined separately. The request methods are:

Password - the static password.

Keyword - a fixed keyword, which can be blank.

PasswordKeyword - the static password followed by a fixed keyword, with no whitespace or separating characters inbetween.

KeywordPassword - a fixed keyword followed by the static password, with no whitespace or separating characters inbetween.

None - no method, the feature is disabled.

Note

If Password is set for the Request Method, and a User's Digipass is still within the Grace Period, Identikey Server may process the authentication with the password only and not as a 2-Step Challenge/Response or Virtual Digipass login.

The static password in the request method is compared against the Digipass User account's password value. However, if the Digipass User account does not have a password set, the password has to be verified with Back-End Authentication. If there is no Back-Back-End Authentication and no password in the Digipass User account, the request methods that use a password will not work.

If the passwords do not match and End Authentication is enabled, the password will be verified with Back-End Authentication.

The methods of requesting these three login processes can be the same. When it recognizes a request, the Identikey Server will verify that there is a Digipass capable of that login process. If there is not, it will ignore the request.

For example, say that the request methods for Primary and Backup Virtual Digipass are both defined as keyword “otp”. A User has a Go 3 with Backup Virtual Digipass enabled. When they login with the keyword “otp”, the Identikey Server will produce a Backup Virtual Digipass OTP, because the User does not have a Primary Virtual Digipass.

2.5.2.7 Multiple Digipass or Digipass Applications

A Digipass User may have multiple Digipass assigned to their User account, and/or multiple Applications enabled for a Digipass. If so, the Identikey Server will need to know which Digipass and Digipass Application will be used for a particular login for the User.

Image 19: Multiple Digipass Assignment

Once the Policy restrictions on Applications and Digipass Types are taken into account, there may still be more than one Digipass Application that could be used. In that case, the Identikey Server will check the OTP with each one. Any one of them can validate the OTP.

A Grace Period may be applied to each Digipass assigned to a Digipass User. Because an applied Policy might restrict which Digipass can be used during a login, the Grace Period on each Digipass is independent of other Digipass. This means that if a User is assigned two Digipass, each with a Grace Period of seven days, the User may log in using one Digipass within the seven-day period (ending the Grace Period for that Digipass) without affecting the Grace Period for the other Digipass.

Example

The company has set up Policies which require a Response Only login via the local area network, and a Challenge/Response login via the internet – limited to certain employees.

John has two Digipass assigned to him – a DP300 with the Challenge/Response application enabled, and a Go 3 with a Response Only application. The Digipass are both assigned on Tuesday.

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 he must use the Go 3 when logging into the intranet from the LAN.

Over the weekend, John needs to access the company intranet from home. Because a Challenge/Response login is required via the 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 period for the DP300, the login is valid.

2.5.3

Authentication without Digipass

When the Digipass lookup does not return a Digipass record, authentication processing requires a static password check to succeed. In addition, Self-Assignment is possible when the Digipass lookup does not return any Digipass.

2.5.3.1 Static Password Verification

The password is compared against the Digipass User account's password value. If the static password is valid, Local Authentication succeeds (but note that Back-End Authentication, if used, can subsequently still cause the overall login to fail).

However, if the Digipass User account does not have a password set, the password has to be verified with Back-End Authentication. If there is no Back-Back-End Authentication and no password in the Digipass User account, authentication without Digipass cannot work. Similarly, during Dynamic User Registration, where there is no Digipass User account yet, the password has to be verified with Back-End Authentication.

If the passwords do not match and End Authentication is enabled, the password will be verified with Back-End Authentication.

If the Local Authentication setting is Digipass Only, static password verification on its own is not permitted. An OTP must be used during login. This is possible using Self-Assignment.

2.5.3.2 Self-Assignment

A User is able to assign a Digipass to their Digipass User account using the Self-Assignment mechanism, when permitted by the Policy settings. The Assignment Mode setting must be Self-Assignment.

In order for Self-Assignment to succeed, the User needs to provide the following: A static password, validated by Back-End Authentication.

The Serial Number of an available Digipass record. A valid OTP for the Digipass.

A new Server PIN, if required.

The Self-Assignment process is possible during Dynamic User Registration. It is also possible when the Local Authentication setting is Digipass Only.

Response Only