IG 100 Deploy Guide

Entrust®

IdentityGuard 10.0

Deployment Guide

Document issue: 1.0

Date of Issue: August 2011

2

Copyright © 2011 Entrust. All rights reserved.

Entrust is a trademark or a registered trademark of Entrust, Inc. in certain countries. All Entrust product names and logos are trademarks or registered trademarks of Entrust, Inc. in certain countries. All other company and product names and logos are trademarks or registered trademarks of their respective owners in certain countries.

This information is subject to change as Entrust reserves the right to, without notice, make changes to its products as progress in engineering or manufacturing methods or circumstances may warrant.

Export and/or import of cryptographic products may be restricted by various regulations in various countries. Export and/or import permits may be required.

Entrust IdentityGuard 10.0 Deployment Guide

TOCTOC

About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Revision information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Documentation conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Note and Attention text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Related documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Obtaining documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Documentation feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Obtaining technical assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Technical support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Telephone numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Email address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Entrust Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

About Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Why use Entrust IdentityGuard? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Issuing digital IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Issuing digital IDs to mobile devices . . . . . . . . . . . . . . . . . . . . . . 22

Issuing digital IDs to smart credentials . . . . . . . . . . . . . . . . . . . . 23

Issuing smart credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Enabling multi-factor authentication . . . . . . . . . . . . . . . . . . . . . . . . . 24

Challenges of first-factor authentication . . . . . . . . . . . . . . . . . . . . . . 25

Benefits of multifactor authentication . . . . . . . . . . . . . . . . . . . . . . . . 25

Identities become difficult to steal . . . . . . . . . . . . . . . . . . . . . . . 25

Stolen identities become difficult to reuse . . . . . . . . . . . . . . . . . 25

Multifactor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

First-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Second-factor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . 26

Mutual authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4

Entrust IdentityGuard components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Entrust IdentityGuard server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Entrust IdentityGuard Authentication service . . . . . . . . . . . . . . . 31

Entrust IdentityGuard Administration service . . . . . . . . . . . . . . . 32

Administration interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Properties editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Master user shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Entrust IdentityGuard Self-Service Module . . . . . . . . . . . . . . . . . . . . 32

Entrust IdentityGuard Federation Module . . . . . . . . . . . . . . . . . . . . . 33

Entrust IdentityGuard Enrollment Module . . . . . . . . . . . . . . . . . . . . 34

Entrust IdentityGuard Print Module . . . . . . . . . . . . . . . . . . . . . . . . . 34

Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

First-factor authentication application . . . . . . . . . . . . . . . . . . . . . . . 35

Entrust IdentityGuard Radius proxy . . . . . . . . . . . . . . . . . . . . . . . . . 35

Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Entrust IdentityGuard Desktop for Microsoft Windows . . . . . . . . . . 36

Entrust IdentityGuard Remote Access Plug-in . . . . . . . . . . . . . . . . . . 37

Entrust IdentityGuard PAM Plug-in . . . . . . . . . . . . . . . . . . . . . . . . . 37

Entrust IdentityGuard ISAPI filter . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Citrix XenApp integration package . . . . . . . . . . . . . . . . . . . . . . . . . . 38

CA SiteMinder integration package . . . . . . . . . . . . . . . . . . . . . . . . . 38

IBM Tivoli Access Manager (TAM) integration package . . . . . . . . . . 38

Client applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Entrust IdentityGuard users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Microsoft Windows desktop users . . . . . . . . . . . . . . . . . . . . . . . 39

Routing and Remote Access Service (RRAS) users . . . . . . . . . . . 39

VPN users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Web users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Mobile users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Smart credential users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .41

Overview of available authentication methods . . . . . . . . . . . . . . . . . . . . . . 42

Entrust IdentityGuard 10.0 Deployment Guide Document issue: 1.0

First-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Password authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Radius server authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

External authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Second-factor authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Token (and soft token) authentication . . . . . . . . . . . . . . . . . . . . . . . 49

Grid authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Determining the grid challenge size . . . . . . . . . . . . . . . . . . . . . . 55

Passcode lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Knowledge-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Out-of-band (OOB) one-time password (OTP) authentication . . . . 60

One-time password delivery systems. . . . . . . . . . . . . . . . . . . . . 61

Certificate authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Mutual authentication methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Grid serial number or grid location replay . . . . . . . . . . . . . . . . . . . . 64

Image and message replay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Machine authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Computer registration process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Sources of machine fingerprint data . . . . . . . . . . . . . . . . . . . . . . . . . 69

Basic Web browser without client-side software . . . . . . . . . . . . 69

Basic Web browser with client-side software . . . . . . . . . . . . . . . 72

Web application (server-side) . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Risk-based authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Setting risk policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Setting authentication policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

IP geolocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Certificates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Blacklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Temporary PIN authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Transaction verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Using personal verification numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

5

6

Smart credential authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83

Planning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Planning: initial considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Entrust IdentityGuard policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

System monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Other precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Planning administrative tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Assigning master users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Assigning administrators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Planning user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Alias and user ID requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Aliases in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . 94

Training users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Providing services to users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Locking users out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Preventing brute force attacks through lockouts . . . . . . . . . . . . 96

Preventing phishing attacks through challenge timeouts . . . . . . 96

PIN-protection lockout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Suspending users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

Group requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Groups in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Groups in an enterprise deployment . . . . . . . . . . . . . . . . . . . . . . . . . 98

Analyzing your company’s group needs . . . . . . . . . . . . . . . . . . . . . . 99

Group implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100


Deployment considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Application integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Web integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Microsoft Windows integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

VPN remote access integration . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Wireless Access Portal integration . . . . . . . . . . . . . . . . . . . . . . . . . 104

Self-Service integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Application considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Integrating with existing user management systems . . . . . . . . . . . 105

Using shared secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Using a Hardware Security Module (HSM) . . . . . . . . . . . . . . . . . . . . . . . 107

Selecting a repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Directory repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

Database repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Performance and maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Performance testing strategies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Backing up, restoring, and migrating from one platform to another . . . . . 113

Switching users over to Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . 114

Creating users in Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . 114

High availability and disaster recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

Entrust IdentityGuard Server hot-standby and load-balancing . . . . 115

Repository failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Local repository failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Geographically-dispersed repository failover . . . . . . . . . . . . . . 118

Radius server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Deploying grid authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Grid requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Grid size and format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Grid size impact. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Grid format impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Grid lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123

Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

7

8

Varying the grid challenge size. . . . . . . . . . . . . . . . . . . . . . . . . 125

Challenge algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126

Grid card production models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

Produce-and-assign model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

Entrust IdentityGuard Self-Service Module eGrids . . . . . . . . . . 128

Producing and assigning physical grid cards . . . . . . . . . . . . . . . 128

Preproduction model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

Forcing grid card activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Grid security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Physical grid card security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

eGrid security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Physical grid card production options . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

In-house grid card production . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Typical characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Outsourced grid card production . . . . . . . . . . . . . . . . . . . . . . . . . . 137


Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Entrust IdentityGuard grid card production . . . . . . . . . . . . . . . . . . . 139


Setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Grid card production cost factors . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Secure file transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Secure email . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Secure FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

Automating processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142


Deploying token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Using tokens for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Token lifetime and replacement . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Allowing users to have multiple tokens . . . . . . . . . . . . . . . . . . . . . 144

Entering token response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

Using soft tokens for transaction verification . . . . . . . . . . . . . . . . . 145

Token deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Deploying hardware tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Assigning tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Forcing token activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

Installing the soft token. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Activating the soft token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

Token security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Deploying knowledge-based authentication. . . . . . . . . . . . . . . . . . . . . . . . 149

Question requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Sources of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Creating good questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Selecting a set of questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153

Challenge requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Challenge accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

Setting how many correct answers are required. . . . . . . . . . . . 155

Setting the accuracy of answers . . . . . . . . . . . . . . . . . . . . . . . 155

Security considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

User life cycle management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

Life cycle management overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

Enrollment of users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Enrolling users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

Enrolling smart credential users . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

User enrollment from LDAP user repository . . . . . . . . . . . . . . . . . . 163

Delivery and activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

Use of authenticators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

9

10

Renewal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Replacement of authenticators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173

Remove canceled grid cards and tokens . . . . . . . . . . . . . . . . . . . . . 173

Remove canceled smart credentials . . . . . . . . . . . . . . . . . . . . . . . . 173

Remove inactive grid cards and tokens . . . . . . . . . . . . . . . . . . . . . . 173

Remove unassigned grid cards and tokens . . . . . . . . . . . . . . . . . . . 174

Synchronize with the repository . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Update images used for mutual authentication . . . . . . . . . . . . . . . 174

Update personal verification numbers . . . . . . . . . . . . . . . . . . . . . . 174

Update IP geographical data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

Entrust IdentityGuard baseline architectures . . . . . . . . . . . . . . . . . . . . . . . .175

Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Evaluation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Standard architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

High availability architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178

Web access architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Web access - evaluation architecture . . . . . . . . . . . . . . . . . . . . . . . 179

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Web access - standard architecture . . . . . . . . . . . . . . . . . . . . . . . . 180

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180

Web access - high availability architecture . . . . . . . . . . . . . . . . . . . 181

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182

VPN remote access architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

VPN remote access - evaluation architecture . . . . . . . . . . . . . . . . . 183

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

VPN remote access - standard architecture . . . . . . . . . . . . . . . . . . . 184

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

VPN remote access - high availability architecture . . . . . . . . . . . . . 185

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Wireless access architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Wireless access - evaluation architecture . . . . . . . . . . . . . . . . . . . . 187

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187

Wireless access - standard architecture . . . . . . . . . . . . . . . . . . . . . . 188


Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Wireless access - high availability architecture . . . . . . . . . . . . . . . . 189

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

Microsoft Windows remote access architectures . . . . . . . . . . . . . . . . . . . 190

Microsoft Windows remote access - evaluation architecture . . . . . 190

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190

Microsoft Windows remote access - standard architecture . . . . . . . 191

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191

Microsoft Windows remote access - high availability architecture . 192

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Generic remote access architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Generic remote access - evaluation architecture . . . . . . . . . . . . . . . 194

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

Generic remote access - standard architecture . . . . . . . . . . . . . . . . 195

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

Generic remote access - high availability architecture . . . . . . . . . . . 196

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

Microsoft Windows desktop architectures . . . . . . . . . . . . . . . . . . . . . . . . 198

Microsoft Windows desktop - evaluation architecture . . . . . . . . . . 198

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

Microsoft Windows desktop - standard architecture . . . . . . . . . . . 199

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Microsoft Windows desktop - high availability architecture . . . . . . 200

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200

Pluggable Authentication Module (PAM) Plug-in architectures . . . . . . . . 202

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202

Self-Service architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

Self-Service - consumer architecture . . . . . . . . . . . . . . . . . . . . . . . 203

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204

Self-service - enterprise architecture . . . . . . . . . . . . . . . . . . . . . . . . 205

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

Federation Module architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

Federation Module - enterprise architecture . . . . . . . . . . . . . . . . . . 211

Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213

Federation Module - SaaS with high availability architecture . . . . . 213

11

12

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Enrollment Module architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

Print Module architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

Mobile enrollment architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220

Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221

Grid card usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223

Entrust IdentityGuard grid card usability study . . . . . . . . . . . . . . . . . . . . . 224

Usability test summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Usability test results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225

Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

General guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Grid card design and layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Use of color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

Design of the grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

Grid authentication implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Web login challenge method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Mutual authentication (through displaying a authentication secret) 229

Temporary PIN length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231


About

About this guide

This guide discusses how to deploy Entrust IdentityGuard in an enterprise or consumer environment.

Note: The guide is not intended to be an exhaustive list of all the activities and tasks required to deploy Entrust IdentityGuard. It acts as a guide for the team responsible for deployment.

This chapter contains the following topics:

• “Revision information” on page 14

• “Documentation conventions” on page 15

• “Related documentation” on page 16

• “Obtaining documentation” on page 17

• “Obtaining technical assistance” on page 18

13

14

Revision informationTable 1: Revisions in this document

Document issue and date

Section Description

1.0

August 2011

All sections First release of this guide.

Entrust IdentityGuard 10.0 Deployment Guide Document issue: 1.0Report any errors or omissions

http://www.entrust.com

http://www.entrust.com/products/feedback/index.cfm

Documentation conventionsTable 2 contains the typographic conventions that appear in this guide:

Table 2: Typographic conventions

Convention Purpose Example

Bold text (other than headings)

Indicates graphical user interface elements and wizards

Click Next.

Italicized text Used for book or document titles

Entrust IdentityGuard Server Administration Guide

Blue text Used for hyperlinks to other sections in the document

Entrust TruePass supports the use of many types of digital ID.

Underlined blue text

Used for Web links For more information, visit our Web site at www.entrust.com.

Courier type Indicates installation paths, file names, Windows registry keys, commands, and text you must enter

Use the entrust-configuration.xml file to change certain options for Verification Server.

Angle brackets

< >

Indicates variables (text you must replace with your organization’s correct values)

By default, the entrust.ini file is located in <install_path>/conf/security/entrust.ini.

Square brackets

[courier type]

Indicates optional parameters

dsa passwd [-ldap]

Note and Attention textThroughout this guide, there are paragraphs set off by ruled lines above and below the text. These paragraphs provide key information with two levels of importance, as shown below.

Note: Information to help you maximize the benefits of your Entrust product.

Attention: Issues that, if ignored, may seriously affect performance, security, or the operation of your Entrust product.

15About this guideReport any errors or omissions

www.entrust.com


16

Related documentationEntrust IdentityGuard is supported by a complete documentation suite:

• For instructions about installing and configuring the Entrust IdentityGuard Server, see the Entrust IdentityGuard Installation Guide.

• For instructions about administering Entrust IdentityGuard users and groups, see the Entrust IdentityGuard Server Administration Guide.

• For a full list and descriptions of the Entrust IdentityGuard master user shell commands, see the Entrust IdentityGuard Master User Shell Reference.

• For information about configuring Entrust IdentityGuard to work with a supported LDAP repository, see the Entrust IdentityGuard Directory Configuration Guide.

• For information about configuring Entrust IdentityGuard to work with a supported JDBC database, see the Entrust IdentityGuard Database Configuration Guide.

• For information about Entrust IdentityGuard error messages, see the Entrust IdentityGuard Error Messages.

• For information about new features, limitations and known issues in the latest release, see the Entrust IdentityGuard Server Release Notes.

• For information about the Self-Service Module, see:

– Entrust IdentityGuard Self-Service Module Installation and Configuration Guide

– Entrust IdentityGuard Self-Service Module Customization Guide– Entrust IdentityGuard Self-Service Module User Guide

• For information about integrating the authentication and administration processes of your applications with Entrust IdentityGuard, see the Entrust IdentityGuard Programming Guide that applies to your development platform (either Java Platform or .NET).

Note: If you are using a programming environment other than .NET or Java, you can still connect applications to Entrust IdentityGuard. Entrust IdentityGuard exposes a standard web-services interface for authentication and administration. The server install ships the WSDL for these services in the <IG_HOME>/client/doc directory. You can translate example code in the .NET and Java guides into other languages.

• For Entrust IdentityGuard product information and a data sheet, go to http://www.entrust.com/strong-authentication/identityguard/index.htm

• For information on identity theft protection seminars, go to http://www.entrust.com/events/identityguard.htm




http://www.entrust.com/strong-authentication/identityguard/index.htm

http://www.entrust.com/events/identityguard.htm

Obtaining documentationEntrust product documentation, white papers, technical notes, and a comprehensive Knowledge Base are available through Entrust TrustedCare Online. If you are registered for our support programs, you can use our Web-based Entrust TrustedCare Online support services at:

https://www.entrust.com/trustedcare

Documentation feedbackYou can rate and provide feedback about Entrust product documentation by completing the online feedback form. You can access this form by

• clicking the Report any errors or omissions link located in the footer of Entrust’s PDF documents (see bottom of this page).

• following this link: http://www.entrust.com/products/feedback/index.cfm

Feedback concerning documentation can also be directed to the Customer Support email address.

[email protected]



https://www.entrust.com/trustedcare/

http://sottwebdev2.entrust.com/products/feedback/index.cfm


mailto:[email protected]

18

Obtaining technical assistanceEntrust recognizes the importance of providing quick and easy access to our support resources. The following subsections provide details about the technical support and professional services available to you.

Technical supportEntrust offers a variety of technical support programs to help you keep Entrust products up and running. To learn more about the full range of Entrust technical support services, visit our Web site at:

http://www.entrust.com/

If you are registered for our support programs, you can use our Web-based support services.

Entrust TrustedCare Online offers technical resources including Entrust product documentation, white papers and technical notes, and a comprehensive Knowledge Base at:

https://www.entrust.com/trustedcare

If you contact Entrust Customer Support, please provide as much of the following information as possible:

• your contact information

• product name, version, and operating system information

• your deployment scenario

• description of the problem

• copy of log files containing error messages

• description of conditions under which the error occurred

• description of troubleshooting activities you have already performed

Telephone numbersFor support assistance by telephone call one of the numbers below:

• 1-877-754-7878 in North America

• 1-613-270-3700 outside North America

Email addressThe email address for Customer Support is:

[email protected]




http://www.entrust.com/resources/index.htm

https://www.entrust.com/trustedcare/

mailto:[email protected]

Entrust Professional ServicesThe Entrust team assists e-businesses around the world to deploy and maintain secure transactions and communications with their partners, customers, suppliers and employees. We offer a full range of professional services to deploy our e-business solutions successfully for wired and wireless networks, including planning and design, installation, system integration, deployment support, and custom software development.

Whether you choose to operate your Entrust solution in-house or subscribe to hosted services, Entrust Professional Services will design and implement the right solution for your e-business needs. For more information about Entrust Professional Services please visit our Web site at:




http://www.entrust.com/services/index.htm

20


1

About Entrust IdentityGuard

Entrust IdentityGuard is a versatile authentication platform that enhances security and verifiability by providing multifactor authentication methods, as well as issuing digital IDs and smart credentials.

Entrust IdentityGuard allows users to prove their identity when accessing sensitive resources from a variety of locations, including the Microsoft Windows desktop, remotely through a VPN connection, or over the Web. Some organizations are leveraging Entrust IdentityGuard over their IVR systems for true cross-channel authentication.

This chapter contains the following sections:

• “Why use Entrust IdentityGuard?” on page 22

• “Multifactor authentication choices” on page 26

• “Entrust IdentityGuard components” on page 29

21

22

Why use Entrust IdentityGuard?There are three main reasons to use Entrust IdentityGuard:

• to issue digital IDs—“Issuing digital IDs” on page 22

• to issue smart credentials—“Issuing smart credentials” on page 23

• to enable multi-factor authentication—“Enabling multi-factor authentication” on page 24

Issuing digital IDsA digital ID is a collection of information that represents a user. Like a passport, the digital ID can be used as an official proof of identity because it has received a stamp of approval by a trusted third-party. In cryptographic terms, this trusted third-party is called a ’Certification Authority’ (CA), and the ’stamp of approval’ is actually the CA’s digital signature.

The digital ID includes, among other things, one or more certificates and private keys that can be used to perform cryptographic operations like authenticating to a network, or applying a digital signature to an email.

What differentiates a digital ID from a regular certificate (as described in “Second-factor authentication choices” on page 26) is that it is managed; that is, it can be revoked by an administrator if it is thought to be compromised, or is no longer of use, for example, when an employee leaves your organization. A key history is also maintained at the CA. This lets users do things like decrypt older emails that were encrypted with a now-expired public key.

Entrust IdentityGuard Server, along with a few other components such as the Self-Service Module and a CA, work together to generate a digital ID. The digital ID can then be:

• issued to a mobile device

• issued to a smart credential (smart card, token, mobile device)

Issuing digital IDs to mobile devicesEntrust IdentityGuard can be configured to issue digital IDs to users’ mobile devices. The mobile enrollment process involves a user going to a self-service Web app supplied by Entrust and clicking an I’d like to request a digital ID link. The request sets off a chain of events between the self-service application, the mobile device, the Entrust IdentityGuard Server, and the CA, which ultimately results in a digital ID being created and installed on the user’s mobile device. All these interactions are not apparent to the user: the only action they need to take is to click a download button when the digital ID is ready to be installed.



Once users have their digital ID, they can use it for various cryptographic functions, such as securing email, or logging in to your corporate network over a VPN connection.

Issuing digital IDs to smart credentialsEntrust IdentityGuard can be configured to issue digital IDs to smart credentials, which include smart cards, USB tokens, and mobile devices.

Digital IDs are encoded by the administrator at the same time as the user personalization data, biometrics, and/or applet, though this must be specified within the smart credential definition (such as in the EnterpriseWithDigitalID.xml sample definition).

Once users have their digital ID on their smart credential, it works alongside the encoded applet to fulfill the required functionality. For example, the combination of the X.509 applet with a digital ID allows users to log into their computers using Windows Smart Card Logon. For more information on applets, see the Entrust IdentityGuard Server Administration Guide.

Issuing smart credentialsSmart credentials exist as various form factors, such as smart cards, tokens, or mobile devices. Entrust IdentityGuard allows administrators to:

• collect user enrollment data and biometrics and encode this data to the smart credential. The information you collect depends on your smart credential definition (see the Entrust IdentityGuard Server Administration Guide for more information about smart credential definitions).

• encode the smart credential with one or more of Entrust’s applets. An applet is a software application that dictates the functionality of the smart credential. For example, if your organization wants the smart credential to provide Smart Card Logon capabilities and grant physical access to your building, you would need to encode the X.509 applet and the Building Access (Proximity) applet to the smart credential.

Note: Some applets, such as X.509 and PIV (all varieties), require the smart credential to include a digital ID as well. See “Issuing digital IDs to smart credentials” on page 23 for more information.

• activate the smart credential during the encoding process. However, administrators can also configure IdentityGuard so that users can activate their own smart credential, provided the applet is already encoded. The activation process involves a user going to a self-service Web application supplied by Entrust and clicking an I’d like to activate a smart credential so I can start using it link.

23About Entrust IdentityGuardReport any errors or omissions


24

Smart credential authentication is discussed further in “Smart credential authentication” on page 83.

Enabling multi-factor authenticationAs online fraud and compliance regulations become more prevalent, standard user name and password authentication no longer offers sufficient security for your organization’s sensitive resources.

Strong authentication is a tool that your organization likely uses in some form today. Whether it is for VPN remote access, Microsoft® Windows® security, or Web-based applications, you need to provide strong and flexible authentication to a wide range of users and transactions, based on the risk associated with those transactions.

Entrust IdentityGuard provides multiple authentication factors (also referred to as “methods”) which your organization can use (with or without other user name and password authentication methods) to increase security. The various authentication methods Entrust IdentityGuard offers allows you to adjust the strength of the authentication to the sensitivity of the resource or transaction.

For example, as Figure 1 demonstrates, a company could apply Entrust IdentityGuard grid authentication when a remote employee logs in using a VPN connection. The system could include an existing user name and password authentication resource or could use Entrust IdentityGuard to handle this first-factor authentication duty.

Figure 1: Multifactor authentication with Entrust IdentityGuard

Employee repository

Entrust IdentityGuard Server

User name and password authentication resource

Company VPN device

Company firewall

User that requires multifactor

authentication



Challenges of first-factor authenticationAuthentication is the process of determining whether someone or something is, in fact, who or what it represents itself to be. In private and public computer networks, authentication is commonly done through the use of a user name and password. The user enters their password to authenticate to the application. This method is referred to as first-factor authentication.

However, the widespread incidents of online identity theft shows that user names and passwords alone—which are easy to steal and easy to reuse—are not much defense against the ever-increasing sophistication of identity attacks. You need one or more second-factor authentication methods to be safe.

Benefits of multifactor authenticationMultifactor authentication is a solution that adds as many authentication methods as required based on the security context. For example, after employees log in using a user name and password, you can require that they answer a grid challenge, while at the same time, have the authentication application check the computers they use to ensure they are registered.

Identities become difficult to stealWith multifactor authentication, it is difficult, if not impossible, for an attacker to steal login data in large numbers. While it is possible to physically steal some authentication data on an individual basis, attackers are usually interested in mass theft. They will get frustrated by the effort. Also, an organization can authenticate itself to its users, making it easier for users to detect redirection to a fraudulent site. The user can then take immediate countermeasures against the likely theft.

Stolen identities become difficult to reuseYour organization can combine multiple authentication methods in ways that make the theft of a single factor useless to the attacker. Without the additional authentication methods, the attacker has either no access to a user’s confidential information or can only view trivial information. Also, authentication can be performed at the transaction level using different authentication methods, depending on the risk associated with the transaction.



26

Multifactor authentication choicesEntrust IdentityGuard offers several ways to set up first-factor authentication. Once the user has logged in, you can apply one or more second-factor authentication methods, and apply additional authentication steps for higher-risk transactions.

First-factor authentication choicesYou can set up Entrust IdentityGuard to do first-factor authentication, or you can integrate Entrust IdentityGuard with an existing authentication resource. Entrust IdentityGuard supports the following types of first-factor authentication:

• password authentication based on a user name and password stored by Entrust IdentityGuard in the user entry of your repository

• external authentication based on domain or directory credentials that a user already has

In addition, Entrust IdentityGuard can integrate with other first-factor authentication methods provided by Web, desktop, or VPN authentication applications. For example, you can integrate Entrust IdentityGuard with Web authentication products such as:

• Entrust GetAccess

• Entrust TruePass

• IIS Web server and Internet Security and Acceleration (ISA) Server

• other third-party applications

You can also integrate Entrust IdentityGuard with Virtual Private Network (VPN) authentication products such as:

• Cisco ASA 5500 Series appliances

• Juniper SSL VPN Routers

You can choose to skip first-factor authentication altogether. Before you do, ensure that you have carefully examined the risks and benefits.

The first-factor authentication methods are described in more detail in “First-factor authentication methods” on page 47.

Second-factor authentication choicesEntrust IdentityGuard provides several second-factor authentication methods, including:

• card (grid and passcode list) authentication

• token authentication

• soft token authentication



• one-time password authentication (typically delivered by an out-of-band mechanism, such as email, voice, or SMS message delivery)

• knowledge-based (question and answer) authentication

• temporary PIN authentication

• certificate authentication

The second-factor authentication methods are described in detail in “Second-factor authentication methods” on page 49. For grid cards, tokens, and temporary PINs, you can include the use of a personal verification number (PVN). See “Using personal verification numbers” on page 82 for more information.

Mutual authentication choicesMutual authentication (also called organization authentication) is a way to verify your organization to users as legitimate. Entrust Identity Guard provides two methods of verifying your organization to users:

• grid serial number or grid location replay

• image and message replay

The mutual authentication methods are described in detail in “Mutual authentication methods” on page 64.

Machine authenticationEntrust IdentityGuard allows you to verify a user by comparing current properties of the user’s machine against a previously stored copy of those same properties. Machine authentication is also a feature of risk-based authentication.

See “Machine authentication” on page 67 for a detailed description of machine authentication.

Risk-based authenticationEntrust IdentityGuard allows you to determine situations where second-factor authentication is applied, based on a user’s location or machine information. For example, second-factor authentication may not be required when users log in from the desktop computer they use all the time. However, if users log in from remote locations or are using computers they have never used before, you may want Entrust IdentityGuard to send them a second-factor challenge. Using risk-based authentication allows you to choose when second-factor authentication is applied based on risks relevant to your company.

There are three authentication features associated with risk-based authentication:



28

• machine authentication

The risk is assessed based on the attributes associated with a particular computer.

• IP geolocation authentication

The risk is assessed based on the geographical location (derived from the IP address) of the user.

• certificate authentication

The risk is assessed based on the validity of a user’s certificate.

See “Risk-based authentication” on page 74 for a detailed description of risk-based authentication.



Entrust IdentityGuard componentsThe following diagrams show how Entrust IdentityGuard can fit into your existing authentication system or become your sole authentication system. Figure 3 shows Entrust IdentityGuard deployed with the Self-Service Module. The module provides self-service functionality that allows the user to administer their cards, grids, tokens, question-and-answer pairs, passwords, and so on.

Figure 2: Entrust IdentityGuard with an existing authentication system


Repository

UserFirst-factor

authenticationapplication

Figure 3: Entrust IdentityGuard as the sole authentication system with the Self-Service Module



30

This section contains the following topics:

• “Entrust IdentityGuard server” on page 30

• “Entrust IdentityGuard Self-Service Module” on page 32

• “Entrust IdentityGuard Federation Module” on page 33

• “Entrust IdentityGuard Enrollment Module” on page 34

• “Entrust IdentityGuard Print Module” on page 34

• “Repository” on page 34

• “First-factor authentication application” on page 35

• “Entrust IdentityGuard Radius proxy” on page 35

• “Reports” on page 36

• “Entrust IdentityGuard Desktop for Microsoft Windows” on page 36

• “Entrust IdentityGuard Remote Access Plug-in” on page 37

• “Entrust IdentityGuard PAM Plug-in” on page 37

• “Entrust IdentityGuard ISAPI filter” on page 38

• “Citrix XenApp integration package” on page 38

• “CA SiteMinder integration package” on page 38

• “IBM Tivoli Access Manager (TAM) integration package” on page 38

• “Client applications” on page 38

• “Entrust IdentityGuard users” on page 39

Entrust IdentityGuard serverThe Entrust IdentityGuard server is the main component of the Entrust IdentityGuard system. You can run more than one Entrust IdentityGuard server in your system, and the servers can access different replicas of the repositories configured for use. See “Repository” on page 34 for more information.

Each Entrust IdentityGuard server includes the following applications and interfaces:

• authentication and administration Web services with Java Platform and .NET APIs

• Administration interface, Properties editor, and master user shell

• a sample Web application that demonstrates Entrust IdentityGuard’s capabilities

These applications and interfaces are required to authenticate and manage users and their authentication data.

Figure 4 illustrates the higher level Entrust IdentityGuard components and shows how they integrate with your existing authentication application.



Figure 4: Entrust IdentityGuard components

Client authentication

application


Entrust IdentityGuard Self-Service

Server

SOAP (SSL is optional)

SOAP (with SSL)

Entrust IdentityGuard Desktop for Microsoft

Windows


Master user shell

Authentication service

Entrust IdentityGuard Radius proxy


Entrust IdentityGuard Administration interface and

Properties editor

HTML/HTTPS

Web administration application

Application server

Repository

Directory

Database

PAM Plug-in

UNIX or LinuxServer

Reports

Administration service

Entrust IdentityGuard Authentication serviceThe Entrust IdentityGuard Authentication service (also referred to as the Authentication API), is a set of Web services used for retrieving challenge requests and authenticating user responses. It is designed to easily integrate with your existing authentication applications to provide multifactor authentication.

You can create an application that calls the Authentication API using its Web service, Java Platform or .NET interfaces to authenticate users. For more information, see the Entrust IdentityGuard Programming Guide that applies to your programming language (Java Platform or .NET).

Optionally, you can use the Secure Sockets Layer (SSL) protocol to secure user responses between any Entrust IdentityGuard authentication client and the Entrust IdentityGuard Authentication service.



32

Entrust IdentityGuard Administration serviceThe Entrust IdentityGuard Administration service (also referred to as the Administration API), is a servlet running on the Entrust IdentityGuard server that manages groups, policies, administrators, users, grid cards, tokens, PINs, and other authentication data.

You can create an application that calls the Administration API using its Web service, Java Platform or .NET interfaces to automate Entrust IdentityGuard user administration tasks. For more information, see the Entrust IdentityGuard Programming Guide that applies to your programming language (Java Platform or .NET).

Administration interfaceAdministrators use the Web-based Administration interface to perform system and user administration operations that define how Entrust IdentityGuard will work in your organization.

Properties editorAdministrators use the Properties editor to set or review the properties that govern the behavior of Entrust IdentityGuard and its components.

Master user shellThe master user shell is a command line interface installed on the Entrust IdentityGuard server. Master users use the master user shell to perform many of the same tasks that the Administration interface offers. A small number of tasks are available only through the master user shell.

Entrust IdentityGuard Self-Service ModuleSelf-Service Module is available for use with Entrust IdentityGuard 9.0 and later. It allows you to give your users the ability to register to Entrust IdentityGuard and to administer their own authentication methods. Some of the actions users can perform for themselves using Self-Service Module include:

• Entering user information (user ID, email address, image replay information, questions and answers, and so on) through a user registration page

• Reporting problems with their authentication methods (lost grid or token, for example) and being automatically issued a temporary PIN for authentication

• Changing passwords or questions and answers for authentication

• Requesting a digital ID

• Downloading the Entrust IdentityGuard Mobile application



Self-Service Module passes this information to Entrust IdentityGuard, which then creates a user entry in the repository, or creates and sends user authentication factors as required.

Note: When using an LDAP user repository, the user must have an entry in the repository before they can be created in Entrust IdentityGuard.

Self-Service Module can be customized for your company’s specific requirements. You can customize the look and feel of the interface, and you can insert your own graphics and logos. You can also customize the workflow followed by users in performing their tasks.

Entrust IdentityGuard Federation ModuleThe Federation Module is available for use with Entrust IdentityGuard 9.3 and later. It acts as a Security Assertion Markup Language (SAML) Identity Provider (IDP) or OpenID provider (OP).

The purpose of the Federation Module is to allow users to log in to partner sites using their first- and second-factor credentials from your organization. This is called multi-factor single sign-on. For example, with the Federation Module, users can access Google services using their corporate email address, password, and Entrust IdentityGuard grid; they do not need to provide Google credentials.

Partner sites can be any SAML or OpenID-enabled Web application or site. For example, a partner site might be:

• a Web application within your organization protected by a Web access management product such as CA® SiteMinder®

• a software as a service (SaaS) or cloud service site outside your organization, such as Google Docs™ and Salesforce.com®

• a site outside your organization that you want to partner with

The Federation Module supports all Entrust IdentityGuard authentication methods, including grid, OTP, Q&A, all types of token and soft token, temporary PIN, mutual authentication, and risk-based authentication. Risk-based authentication includes client-side SSL certificates, IP-geolocation, and machine authentication.

You can integrate the Federation Module with the Self-Service Module to allow users to do things like recover a forgotten password. See “Entrust IdentityGuard Self-Service Module” on page 32 for details.

The Federation Module has passed SAML 2.0 interoperability testing conducted by the Liberty Alliance for the IDP, IDP Lite, SP, and SP Lite operational modes. Note that SP and SP Lite modes are only supported for testing. Entrust GetAccess provides a full Service Provider implementation for SAML 2.0 deployments.



34

For more information about the Federation Module, see “Federation Module architectures” on page 211.

Entrust IdentityGuard Enrollment ModuleThe Enrollment Module is available for use with Entrust IdentityGuard 10.0 and later. It is an application that allows Entrust IdentityGuard administrators with the proper permissions to create new smart credentials and edit existing smart credentials. By default, the Smart Credential Enroller role includes the permissions required to create and edit smart credentials.

Entrust IdentityGuard Print ModuleThe Print Module is available for use with Entrust IdentityGuard 10.0 and later. It is a server application that allows Entrust IdentityGuard administrators with the proper permissions to print and encode smart credentials. By default, the Smart Credential Issuer role includes the permissions required to print and encode smart credentials.

RepositoryEntrust IdentityGuard uses your existing repository or multiple repositories to store user, unassigned token, and preproduced card data in an existing LDAP-compliant directory, a JDBC-compliant database, or both. Multiple Entrust IdentityGuard servers can access different replicas of the repositories, if required.

When a grid or other authentication data is generated for a user, sensitive data is written in encrypted form to the repository. During second-factor authentication, data is retrieved from the repository.

Users reside in groups. You can assign groups to one or more repositories, and those repositories can be in databases, in directories, or both.

Each directory search base is treated as a separate repository, and has the capability of using a different directory server and different directory user credentials. The default configuration uses a single search base.

For grid or token authentication, unassigned token information and preproduced grids are stored in the Entrust IdentityGuard repository. If you are using a database, the unassigned grids and tokens are stored there. If you are using an LDAP repository, you also have the option of storing this information as a flat file. For more information on the file-based repository options, see the Entrust IdentityGuard Installation Guide. When the grid or token is assigned to a user, the information is copied into the user's repository entry.

For more information about repositories, see “Selecting a repository” on page 108.

You can also set up all key connections in a failover scenario. For a database or directory, you can use the Properties Editor to add multiple URLs to the Entrust IdentityGuard properties file. Entrust IdentityGuard attempts to connect to the



repositories in the order they are listed. In the same way, you can list multiple URLs for Radius proxy connections and external authentication connections.

For more information on failover, see “High availability and disaster recovery” on page 115.

First-factor authentication application You have three choices for first-factor (user login) authentication:

• You can integrate Entrust IdentityGuard with your existing authentication application. This authentication application can be a Remote Authentication Dial In User Service (Radius) server, a domain controller, a Web-based access control product, the Microsoft Windows Login feature, an LDAP-compliant directory, and so on. Depending on the type of application, you may need to customize it. For more information, see “Deployment considerations” on page 101.

• You can configure Entrust IdentityGuard to manage user logins through the password feature. In this case, the repository stores password credentials. Administrators can manage the passwords through the Administration interface.

• You can configure Entrust IdentityGuard (when using the Radius proxy) to skip first-factor authentication and move directly to second-factor authentication.

Entrust IdentityGuard Radius proxyThe Entrust IdentityGuard Radius proxy component is installed with the Entrust IdentityGuard Server to enable multifactor authentication for Virtual Private Network (VPN) users and users on Wireless Access Points (WAP).

The Radius proxy intercepts messages between the VPN server and the first-factor authentication resource. That resource may be a Radius server, a Windows domain controller, an LDAP-compliant directory, or Entrust IdentityGuard itself (using password authentication). If the resource is a domain controller or directory, you must use external authentication (see “External authentication” on page 48). For more information, see the Entrust IdentityGuard Server Administration Guide.

In the case of the Radius proxy being used with a wireless access point, all you need is Entrust IdentityGuard—no Radius server or Windows domain controller is required.

The Radius proxy supports second-factor authentication using a grid, a token, questions and answers (knowledge-based), or one-time password (OTP). All of these authentication methods, except knowledge-based and certificate authentication, can also include a personal verification number (PVN). A PVN is similar to a PIN, except it is not tied to one authentication method.



36

ReportsEntrust IdentityGuard provides the ability to generate reports. You can use the reporting feature to create reports that include details about users, grids, cards, tokens, and audits. You can produce reports in PDF or CSV format for printing or importing into another application. Reporting permissions are restricted based on the roles you assign to administrators, so administrators can generate reports based only on the information they have permission to see.

Entrust IdentityGuard Desktop for Microsoft WindowsEntrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that communicates with the Entrust IdentityGuard Server. Table 3 describes the features of Entrust IdentityGuard Desktop for Windows.

Table 3: Features of Entrust IdentityGuard for Microsoft Windows

Feature Feature environment Feature description

Windows Login Microsoft Windows Server 2003, 2008, Windows Vista, Windows 7 the Entrust IdentityGuard Desktop for Microsoft Windows release notes for details

The Windows Login feature of the Entrust IdentityGuard Desktop for Microsoft Windows allows users to use grid authentication when they log in to their Microsoft Windows desktop computer.

Remote Access Windows 2003 The Remote Access feature of the Entrust IdentityGuard Desktop for Microsoft Windows enables users to remotely access a network through dial-up or VPN connectivity.

When Remote Access is installed on the Microsoft Windows desktop computer, a separate product called the Remote Access Plug-in for Microsoft Windows Server (“Entrust IdentityGuard Remote Access Plug-in” on page 37) must be installed on a Microsoft Server machine.

Note: You can use only grid or token authentication with the Remote Access feature.

Entrust IdentityGuard Desktop for Windows is deployed using a Windows installer (MSI) file. You can customize the installer file by applying a transform (MST) file, which is a collection of changes applied to a base MSI file. A central administrator creates a custom installation file and configures the Entrust IdentityGuard options in accordance with your organization’s policies and practices.



In the following scenario, each user in your company has a grid card and may have a temporary PIN. When the computer boots up, Microsoft Windows challenges each user for a Windows user name and password. After the user responds correctly, Entrust IdentityGuard Desktop for Windows displays a challenge box.

• If the user enters the correct response, the users is granted access to the computer.

• If the user enters several incorrect responses and exceeds the lockout limit, the user is locked out of the computer.

• If the user does not have a grid card (for example, the user lost it), the user can enter a temporary PIN, which Entrust IdentityGuard Desktop validates.

• If the user is offline, the user can enter an offline temporary PIN, which Entrust IdentityGuard Desktop validates against the shared secret stored (in encrypted format) in its repository.

For more information, see the Entrust IdentityGuard Desktop for Microsoft Windows Administration Guide.

Entrust IdentityGuard Remote Access Plug-inThe Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server communicates with the Entrust IdentityGuard Desktop for Microsoft Windows Remote Access feature.

For the Remote Access feature to connect to a Remote Access Server, the Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server must be installed on a Windows 2003 Server hosting one of the following:

• Microsoft Routing and Remote Access Service (RRAS)

• Microsoft Internet Authentication Service (IAS)

Usually, the RRAS and IAS are on the same computer. If your setup requires these to be on separate computers, it is recommended that you install the Remote Access Plug-in on the computer hosting the IAS.

When the Remote Access Plug-in for Microsoft Windows Server is installed, an Entrust IdentityGuard Desktop for Microsoft Windows Remote Access client has the ability to connect to the Entrust IdentityGuard Server for second-factor authentication.

See the Entrust IdentityGuard Desktop for Microsoft Windows Administration Guide for more information.

Entrust IdentityGuard PAM Plug-inThe Entrust IdentityGuard Pluggable Authentication Module (PAM) Plug-in integrates a UNIX or Linux server with Entrust IdentityGuard 9.0 and later.



38

The integration provides strong, second-factor authentication to your UNIX and Linux systems using Entrust IdentityGuard. Any application supporting the PAM framework can make use of Entrust IdentityGuard, provided that the application can prompt users for additional authentication.

This integration works with Entrust IdentityGuard passwords, grids, tokens, temporary PINs, one-time passwords, knowledge-based questions and answers, and personal verification numbers.

Entrust IdentityGuard ISAPI filterEntrust IdentityGuard can protect Web applications (such as Microsoft Outlook Web Access) with the Entrust IdentityGuard ISAPI filter. You can install the ISAPI (Internet Server Application Programming Interface) filter on an ISA server or an IIS server.

The Entrust IdentityGuard ISAPI filter, combined with any Entrust IdentityGuard authentication method, ensures that only valid users have access to your Web application.

Citrix XenApp integration packageEntrust makes available a Citrix XenApp integration package. When installed, users accessing published applications through the Citrix Web Interface are required to authenticate using an Entrust IdentityGuard second-factor authentication method.

CA SiteMinder integration packageEntrust makes available a Custom Authentication Scheme (CAS) for use with SiteMinder. When the CAS is installed into SiteMinder’s authentication framework and assigned to SiteMinder resources, users accessing these resources are required to authenticate using an Entrust IdentityGuard second-factor authentication method.

IBM Tivoli Access Manager (TAM) integration packageEntrust makes available a package called the ’Entrust TAM integration’. This package is also known as the Entrust EAI. When this package is installed, Entrust IdentityGuard second-factor authentication can be used to authenticate users of specific WebSEAL junctions.

Client applicationsClient applications use the Authentication API and the Administration API to access Entrust IdentityGuard’s multifactor authentication abilities on behalf of your users. To access these APIs, the client applications require appropriate administrative privileges. The following list provides some examples of what client applications can do.



• presenting users with an initial authentication page (user name and password) when they attempt to access your site

• challenging users with a second-factor authentication page, using challenges created by Entrust IdentityGuard

• providing the challenge response to Entrust IdentityGuard for validation

• returning the Entrust IdentityGuard response to the user

To create your own client applications, see the Entrust IdentityGuard Programming Guide that applies to your programming language (Java Platform or .NET).

The Entrust IdentityGuard Administration interface, Entrust IdentityGuard Desktop for Microsoft Windows, and the sample Web application included in the installation package are all examples of client applications.

Entrust IdentityGuard usersEntrust IdentityGuard users are divided into different categories, based on how they access your organization’s resources. See “Entrust IdentityGuard baseline architectures” on page 175 for diagrams showing how Entrust IdentityGuard interacts with these users.

Microsoft Windows desktop usersMicrosoft Windows desktop users are internal users who, after logging in to your domain using their Windows user name and password, are then presented with a second-factor authentication challenge (such as a grid challenge). For more information about these users, see the Entrust IdentityGuard Desktop Client for Microsoft Windows Administration Guide.

Routing and Remote Access Service (RRAS) usersRRAS users are Microsoft Windows users internal to your organization who access your domain remotely through a dial-up, wireless, or VPN connection and use the Microsoft Routing and Remote Access Service. After logging in to your domain, they are then presented with a second-factor authentication challenge (such as a grid challenge). For more information about these users, see the Entrust IdentityGuard Desktop Client for Microsoft Windows Administration Guide.

VPN usersVPN users are internal and external users who log into your domain using a VPN connection. First-factor authentication (user name and password) can be provided by:

• an existing Radius server



40

• an existing LDAP directory

• an existing Windows domain controller

• Entrust IdentityGuard password authentication

Entrust IdentityGuard then challenges these users for a second factor of authentication. For more information, see “VPN remote access integration” on page 103.

Web usersWeb users are internal or external users to your organization who access your intranet or Internet site by logging in through a Web browser. First-factor authentication (user name and password) is completed by a Web access product or Entrust IdentityGuard using password authentication. Entrust IdentityGuard can then provide additional authentication methods as required by the sensitivity of the operation. For more information, see “Web integration” on page 102.

Mobile usersMobile users are internal or external users to your organization who authenticate to your application using a one-time password generated on their mobile device by the Entrust IdentityGuard Mobile soft token. For details, see “Self-Service integration” on page 104.

Smart credential usersDepending on the applet encoded on the smart credential, smart credential users can authenticate to physical and/or logical resources.



2

Authentication methods

Entrust IdentityGuard provides authentication methods for authenticating users, performing mutual and risk-based authentication, and registering computers.

This chapter describes the implementation considerations for each method.

Note: While reading this chapter, consider the frequency of the authentication events to which you want to add multifactor authentication. Gather statistics from your authentication applications and resources, and develop a usage profile for each of the transactions. You can then find an appropriate balance between user convenience, resistance to attack, and the administrative overhead for managing multifactor authentication.


• “Overview of available authentication methods” on page 42

• “First-factor authentication methods” on page 47

• “Second-factor authentication methods” on page 49

• “Mutual authentication methods” on page 64

• “Machine authentication” on page 67

• “Risk-based authentication” on page 74

• “Temporary PIN authentication” on page 78

• “Transaction verification” on page 79

• “Using personal verification numbers” on page 82

41

42

Overview of available authentication methodsThis section describes and compares the authentication methods available through Entrust IdentityGuard.

Entrust IdentityGuard divides the authentication methods into the following categories:

• first-factor authentication

In first-factor authentication, users must identify themselves, typically by supplying a user name and password. You can rely on a separate application to do this, such as a Remote Authentication Dial In User Service (Radius) server, a domain controller, a Web-based access control product, or the Microsoft Windows Login feature. Alternatively, you can use Entrust IdentityGuard’s password feature.

Figure 5: First-factor authentication

• second-factor authentication

In second-factor authentication, users verify their authenticity to your organization, using one of the following methods:

– token authentication– soft token authentication (through the Entrust IdentityGuard Mobile and

Entrust IdentityGuard Soft Token applications)– grid authentication– passcode list authentication– knowledge-based authentication– one-time password authentication, typically delivered through an

out-of-band mechanism– certificate authentication



Figure 6: Second-factor authentication methods

For added security, a personal verification number can be used with cards (grids and passcode lists), tokens, soft tokens, and one-time-passwords. For more information, see “Using personal verification numbers” on page 82.

• mutual authentication (organization authentication)

In mutual authentication, your organization proves itself as authentic. Mutual authentication can involve different types of replay authentication.

Figure 7: Mutual authentication methods

Serial replay authentication(grid card serial number )

Message replay authentication (user entered

message)

Grid location replay authentication (grid locations shown specific to

user)

Image replay authentication

(user selected image )

43Authentication methodsReport any errors or omissions


44

• machine authentication

In machine authentication, the user’s identity is verified based on various properties of the user’s computer.

• risk-based authentication

In risk-based authentication, the authentication method presented depends on the risk. Risk varies based on user qualities, such as

– the machine used– the user’s geographic location– the presence of a valid certificateRisk can be based on the nature of the transaction, an applications can indicate that an authentication is higher risk at specific points during a transaction. Some example transactions that might qualify as high-risk include:

– large money transfers– new account creation– large purchases

• temporary PIN authentication

In temporary PIN authentication, the user enters a temporary PIN in place of a temporarily unavailable card (grid or passcode list) or token.

The Entrust IdentityGuard Server installs with a sample Web application that demonstrates how the various authentication methods work, and how you can set up your own applications to integrate with the Entrust IdentityGuard system. The Entrust IdentityGuard Installation Guide includes a tutorial that describes the Web application.

To deploy the authentication methods, Entrust IdentityGuard includes policies that allow you to determine the characteristics of the authentication methods for groups of users. For more information, see “Entrust IdentityGuard policies” on page 87 and the Entrust IdentityGuard Server Administration Guide.

Table 4 on page 44 provides a brief comparison of the Entrust IdentityGuard authentication methods.

Table 4: Comparison of available authentication methods

Authentication method

Physical requirements for users

Renewal options1 Sample use

Password None Based on time Requiring first-factor authentication



Token Token hardware When device is lost or battery dies (6 years or more)

Requiring strong second-factor authentication

Soft token Computer with Entrust IdentityGuard Soft Token installed, or a mobile device with Entrust IdentityGuard Mobile installed

Software update Requiring strong second-factor authentication

Grid Card

eGrid

Based on use or time Requiring strong second-factor authentication

Passcode list Printed list Based on use or time Requiring infrequent authentication

Temporary PIN None Based on use or time Grid, passcode list, or token is temporarily unavailable

Knowledge-based None N/A Registering users and/or machines

One-time password delivered by an out-of-band mechanism

None2 One-time use only (usually)

Optional automatic replacement

One-time, highly sensitive operation

Machine (can be part of risk-based authentication)

N/A Based on each login, length of time, or when users change computers

Users access site from personally-owned computers

IP geolocation (risk-based)

N/A N/A Users access site from a variety of locations

Certificate N/A Usually a time limit; issue a new certificate

Authentication with or without explicit user response

Smart credential Smart card or USB token3

Usually a time limit; issue a new certificate

Authentication with or without explicit user response

Table 4: Comparison of available authentication methods (continued)






46

Replay (organization) Card, if using grid location or serial number replay

N/A Verification of organization

1. An administrator or application can force a renewal at any time.2. Users need a telephone number, an SMS-capable device, or email account to receive the one-time password by

out-of-band delivery.3. Users need an SMS-capable device or email address if you will send smart credential information by out-of-band

delivery.

Table 4: Comparison of available authentication methods (continued)






First-factor authentication methodsYou can use Entrust IdentityGuard to directly manage first-factor authentication; that is, to check if a user’s first-factor credentials (user name and password) are valid. Alternatively, you can configure Entrust IdentityGuard to use an external authentication mechanism, such as a Windows domain controller. You can always integrate Entrust IdentityGuard with your existing authentication application using the Entrust IdentityGuard authentication and administration Web services.

Password authentication Entrust IdentityGuard administrators with the applicable role permissions can set and manage the passwords of Entrust IdentityGuard users through the Administration interface. For new passwords, administrators can enter passwords of their choosing or auto-generate random passwords. Administrators can also manage policy settings related to passwords, such as the length, composition (letters, numbers, case, and special characters), expiry date, and reuse history. The policy settings ensure that user passwords conform to your organization’s password requirements.

Radius server authenticationFor first-factor authentication of your VPN users, Entrust IdentityGuard provides the ability to use the Radius authentication protocol with a VPN server and optionally, a Radius server.

When you integrate Entrust IdentityGuard with your VPN server, the Entrust IdentityGuard Radius proxy intercepts messages between the VPN server and the first-factor authentication resource.

Entrust IdentityGuard supports these first-factor authentication methods for VPN users:

• Entrust IdentityGuard forwards a request to a Radius server which completes the first-factor authentication.

• Entrust IdentityGuard forwards a first-factor authentication request to either an LDAP-compliant directory or Windows domain controller. This is referred to as external authentication. For more information on external authentication, see “External authentication” on page 48.

• Entrust IdentityGuard itself completes the password authentication.

Regardless of the method, the VPN server still believes it is communicating with a Radius server. It is actually communicating with the Entrust IdentityGuard Radius proxy.

You can configure your VPN servers to use different first-factor authentication resources for first-factor authentication. For example, one VPN server can use a Radius server, and another VPN server can use an LDAP-compliant directory.



48

Note: You can also configure the Radius proxy to skip first-factor authentication entirely and present users with a second-factor authentication challenge immediately.

External authenticationThe external authentication feature, provided with Entrust IdentityGuard is useful when deploying in a Remote Access or VPN environment. This feature lets you use Entrust IdentityGuard to manage first-factor authentication through an LDAP directory or Windows domain controller through Kerberos, without having to deploy a Radius server.

Use external authentication when your users and their password information are stored in an external resource (such as Active Directory or an LDAP-compliant directory).

Also, in an environment where user password information is stored in an external resource (for example, Active Directory) and Entrust IdentityGuard information (grids, tokens, policies, and so on) is stored in a database, you can have Entrust IdentityGuard forward first-factor authentication to the external resource if the external authentication is through Kerberos.

Note: When using external authentication, users in the first-factor resource are not automatically synchronized with the second-factor resource (the Entrust IdentityGuard repository). You must manually synchronize all data between the different resources.

For a sample architecture, see “Web access - evaluation architecture” on page 179. Also see the Entrust IdentityGuard Installation Guide for more information.



Second-factor authentication methodsYour organization can choose one or more second-factor authentication methods. The choice of authentication method depends on the risk of a given transaction or the sensitivity of your resources. The greater the risk of misrepresentation and fraud, the greater the need for additional authentication. While first-factor authentication uses information the user knows, second-factor authentication challenges often also require something the user is holding, a grid card or token, for instance.

Second-factor authentication is also used in step-up authentication. A user may be authenticated, and working in the application, but then they request a higher risk transaction, for example a $10,000 transfer from one account to another. If step-up authentication is enabled, the user is challenged again before being able to complete the $10,000 transfer.

Another way to implement step-up authentication is to have Entrust IdentityGuard send the transaction details (such as the ‘To’ and ‘From’ accounts and the amount of money transferred) to the user through an out-of-band method such as SMS or email before allowing a transaction to proceed. Users are then asked to confirm the transaction. This out-of-band scheme mitigates the risk of "man-in-the-middle" attacks, because it allows the user to independently verify that the transaction has not changed between the initial transfer request and the authentication.

Note: If users have a mobile device, they can install the Entrust IdentityGuard Mobile application to have transaction details sent to this application instead of through an email or SMS. This approach does not incur the delivery charges associated with email and SMS and might be a cheaper option for your organization. See “Transaction verification” on page 79 for details.

The following second-factor authentication methods are available:

• “Token (and soft token) authentication” on page 49

• “Grid authentication” on page 51

• “Passcode lists” on page 56

• “Knowledge-based authentication” on page 58

• “Out-of-band (OOB) one-time password (OTP) authentication” on page 60

• “Certificate authentication” on page 62

Token (and soft token) authenticationUsing tokens, your users can authenticate using a dynamic password after completing first-factor authentication.



50

By default, Entrust IdentityGuard supports a number of different token formats that can be deployed alone or in combination, based on your organization’s unique requirements. These include:

• Entrust IdentityGuard Mini Tokens

Available in an OT version (OATH compliant time synchronous) and an AT version (time + event synchronous)

• Entrust IdentityGuard Pocket Tokens

• Entrust IdentityGuard DisplayCard Tokens

• soft tokens available in Entrust IdentityGuard Mobile and Entrust IdentityGuard Soft Token

• Entrust IdentityGuard SMS/Email-based Soft Tokens

Figure 8 shows the Entrust IdentityGuard Mobile soft token. The dynamic password (called a ’security code’) is presented to users on their mobile device, and users enter this number onto your Web site to authenticate.

Figure 8: Entrust IdentityGuard Mobile dynamic password

Please consult token documentation on the Entrust TrustedCare Web site for a description of each token.



You can configure Entrust IdentityGuard to use any tokens from a supported token vendor. Different token types can be assigned to your users, and a user can have two tokens from different vendors.

Tokens represent a strong second-factor authentication method because they combine possession (the token) and knowledge (the dynamic password or PIN). Because the token password changes frequently, it is difficult for a hacker to record it and use it later to log in to the system.

Entrust IdentityGuard supports tokens that use response-only mode and tokens that use challenge-response mode. Soft tokens are only supported in response-only mode.

Table 5: Token authentication advantages and considerations

Advantages • It is easy to use.

• It is impossible for an attacker to reuse passwords, making it a very secure second-factor authentication method.

• Soft tokens are just as cost efficient to buy, maintain, and renew as other methods such as grids.

Considerations • Hardware tokens are not as cost efficient to buy, maintain, and renew as other methods (such as grids). Entrust hardware tokens are more cost efficient than hardware tokens from other vendors.

• You need to determine how to roll out tokens and train users.

• For time-based tokens, the Entrust IdentityGuard Server clock must be accurate to UTC within a 30-second range.

• Instead of hardware tokens, consider using soft tokens, which are a software-only version of a hardware token. Soft token applications such as Entrust IdentityGuard Mobile and Entrust IdentityGuard Soft Token can be installed easily on users’ mobile devices and computers, respectively. The software is also easy to replace and maintain: users simply install a new version of the software, or reactivate it if problems arise.

Deployment types • Web access

• Microsoft Windows remote access

• VPN remote access

Grid authenticationWith grid authentication, you provide each user with a printed Entrust IdentityGuard card that contains rows and columns of characters. Authentication works as follows:

1 The user completes first-factor authentication (user name and password) successfully.



52

2 Entrust IdentityGuard presents the user with a challenge based on the grid on their card, as illustrated in Figure 9.

3 The user enters the values from their grid card corresponding to the requested cell locations in the challenge. In Figure 9, the challenge asks the user to enter the numbers in grid coordinates B1, E4, and G5, which are “7 8 4”.

4 Entrust IdentityGuard validates the entered values and authenticates the user. By entering the correct response, users demonstrate that they possess the grid card, thus providing a second factor of authentication.

Figure 9: Entrust IdentityGuard challenge sample

************

IGuser1

You can set up grid challenges in one of the following ways:

• In one-step authentication, you combine first and second-factor authentication on a single page. For example, you include the prompt for a user name, a password and a grid challenge on one page. In this approach, the application does not know the user’s identity until after login and authentication; that is, the user is anonymous until both first and second-factor authentication are complete. For an example, see Figure 10.



Figure 10: One-step authentication example

• In two-step authentication, the user logs in as usual and is then shown a second dialog box containing the Entrust IdentityGuard grid challenge. Because the user has already passed first-factor authentication, the user’s identity is known. This lets you add other Entrust IdentityGuard features, such as serial number replay or grid location replay (see “Mutual authentication methods” on page 64). For an example, see Figure 11 on page 54.



54

Figure 11: Two-step authentication example

Table 6 lists the advantages and considerations of grid authentication.

Table 6: Grid authentication advantages and considerations

Advantages • It is easy to use (see “Entrust IdentityGuard grid card usability study” on page 224).

• It is inexpensive to set up, maintain, and renew.



Determining the grid challenge sizeThere may be cases where you want to present a different number of grid coordinates based on the type of access or transaction the user requires. For example, access to a company information portal could require two grid coordinates while access to a online investment site could require four coordinates.

You set the minimum and maximum number of required grid coordinates in Entrust IdentityGuard policy, and then set the exact number of coordinates for each

Considerations • The standard size of a grid card is a 5 x 10 grid, which contains 19,600 three-cell challenge sets. This size provides both security and usability. You can customize the grid size to meet your unique deployment, usability, and security requirements.

• Replace grids on a regular basis. Determine the frequency of grid replacement based on your users’ needs and your security requirements.

• Determine whether you need one-step or two-step authentication options (two-step is recommended).

• If you are also running Entrust IdentityGuard Self-Service Module, you can issue eGrids by sending them by email. An eGrid is a grid sent to the user in a file, rather than on a card. Users can print their eGrid files, or use them from their computers by viewing the file when they need to authenticate.




• Microsoft Windows desktop

Deployment risks and mitigation

• Through mechanisms such as phishing or pharming, an attacker can capture one or more grid authentications made by a user and attempt to authenticate to the legitimate application. Set up your lockout policy to ensure a limit on the number of attempts, and replace grid cards regularly to help mitigate this risk.

• Grids must be processed and delivered securely to the user so that no grid information is copied before the user obtains the grid. Consider using Entrust IdentityGuard Card Production Service (available through Entrust TrustedCare online) to ensure that grid card security is maintained throughout the deployment process.

• If emailing eGrids, users should be instructed on maintaining email security.

Table 6: Grid authentication advantages and considerations (continued)



56

authentication scenario in your application. The application must present a number of coordinates between the minimum and maximum number of required coordinates.

Passcode listsPasscode list authentication is a grid authentication that uses a list of passcodes or transaction numbers (TANs) rather than a grid. Each passcode can be used just once. With this approach, you provide users with a list of randomly generated passcodes for second-factor authentication.

Some organizations view passcode lists as easier for their users to use than grid cards, though our usability study proved that grid card use is quick to learn. (See “Grid card usability study” on page 223.)

Typically, you distribute these lists to users on a printed sheet of paper similar to Figure 12. You can also distribute scratch-off grid cards that make it easy for users to see what codes they have already used.

Figure 12: Sample passcode list

Then, when a passcode is required, you prompt for the passcode next to a number in the list as in Figure 13.



Figure 13: Sample passcode prompt

The user types the passcode printed on the paper next to the requested number. To reduce susceptibility to phishing or malware attacks, each passcode is used just once. This renders the entered passcode useless should it be captured by an attacker.

To help users remember they can use each passcode only once, and to help them keep track of when they need a new passcode card, recommend that they strike used passcodes from the list. Alternatively, create your passcode list as a scratch card, which only reveals the passcode once a covering is scratched off.

Table 7: Passcode list authentication advantages and considerations

Advantages • Single use of a password makes it impossible for attackers to reuse authentication data.

• You can create multiple passcodes at once, lowering overhead.

Considerations • Much like the grid production process, you need to produce and distribute the passcode lists to your users. Unlike grids, however, you will typically want to send users more than one list at a time. Research your past authentication histories to determine how fast the average user will exhaust a list and send an appropriate number of lists to ensure that users can always authenticate.

• Additional consideration should be given to the way a passcode list is produced, such as whether it will be a simple list of uncovered passcodes or a covered list much like a lottery scratch card. Cost is the primary difference between these two options.

• The number of characters in each passcode should be between five and nine to maintain a balance between security and usability.

• Choose between numeric or alphanumeric passcodes.

Deployment type • Web access



58

Knowledge-based authenticationA simple mechanism for identifying users is to challenge them to provide information that an attacker likely cannot provide. The organization can present questions to the user based on information (referred to as authentication secrets) that was supplied by the user at registration or based on previous transactions or relationships.

In turn, the users recognize the secret questions they set up during registration and they know that they have reached a legitimate site.

During enrollment the user may select and provide answers to easily-remembered questions, such as What year did you buy your first car?, Which historical figure do you most admire?, Name your most memorable cartoon character?, and so on.

Questions can be drawn from previous user interactions with the organization. For example: What was the balance on your last statement?. It is difficult for attackers to harvest answers to these questions through other information sources.

Entrust IdentityGuard allows organizations to select a number of such authentication secrets or facts for each user and prompt for all answers or just a subset of them to increase second-factor authentication strength.

Figure 14: Sample question-and-answer prompt

By maintaining a large set of authentication secrets, organizations can select a subset that makes it more difficult for an attacker to gather impersonating information based on previous authentications.


• Some phishing attacks target this form of authentication.

There are simple ways to increase the security of a passcode list. For example, prompt for passcodes in a random order instead of from first to last, or add another form of authentication (such as machine authentication) along with a passcode list.

Alternatively, consider deploying grid authentication instead of a passcode list.

Table 7: Passcode list authentication advantages and considerations (continued)



To make it easier on users, you can use questions and answers for additional authentication rather than as your main second-factor authentication method. For example, use machine authentication for the user’s normal login location and reserve the questions for when the user logs in from a different machine.

Table 8: Knowledge-based authentication advantages and considerations

Advantages • There are no physical requirements for users (such as grid cards or tokens).

• You can leverage previous interactions between the user and your organization.

Considerations • Consider how you will generate knowledge-based questions, such as generated codes or pre-populated lists. See “Sources of questions” on page 150.

• Good questions follow the criteria for privacy, security, and usability. See “Creating good questions” on page 151.

• Users do not like answering a large number of questions.

• Allowing inexact answers by using a word map file can compensate for users entering some incorrect values (such as “St.” instead of “Street”).

• If the user must answer a large set questions to authenticate, you may wish to allow a few incorrect responses.

• Select how many questions a user must answer based on your security needs. More sensitive activities may require more questions.




• User-generated question-and-answer sets are not always secure.

• Users do not always enter secure answers to questions.

When prompted to create their own questions and answers, users can enter questions and answers that are easy to guess or easy to find. Consider providing the user with a stock list of questions instead.

Even when providing the user with a stock list of questions to answer, users can enter answers that are not secure (such as sequential keyboard sequences or repeated answers). Be sure to validate the answer set so it meets security needs. Alternately, consider using a different method for generating questions (“Sources of questions” on page 150).



60

Out-of-band (OOB) one-time password (OTP) authenticationThere are situations where you want to provide users with an authentication method that, for security reasons, must be outside of the user’s current online session. For example, a user attempts to execute a high-risk transaction (such as transferring funds to a foreign bank), and you want to provide extra authentication. By using means other than the primary communication channel (the user’s computer and your network), you make it more difficult for an attacker or fraud attempt to succeed. This is referred to as Out-Of-Band (OOB) authentication.

Entrust IdentityGuard supports this capability by generating one or more one-time passwords you can send to the user.

Note: Another out-of-band form of authentication is transaction verification using Entrust IdentityGuard Mobile. See “Transaction verification” on page 79.

In the default configuration, one password is sent when the user requests authentication. While this is effective most of the time, in cases where the user is unable to receive a one-time password (cell phone out of range, no access to email), the user may be unable to authenticate. If this is a likely situation in your organization, you can configure Entrust IdentityGuard to send multiple out-of-band passwords at one time, after authentication, so that the user has spare passwords to use for the next login.

Each OTP is deleted when it is used for authentication, and the same OTP is never accepted more than once. When the multiple OTP feature is enabled, and the number of valid OTPs assigned to the user falls below a threshold you set, more OTPs are automatically sent to the user. The OTPs are sent using the out-of-band method configured.

You can send one-time passwords directly using email, text message (SMS), or voice to a preregistered phone number. The user gets the one-time password by one of these means, enters it into the application, and the transaction is approved.

To decide how to send the one-time password, consider the following:

• What information is already stored about the user and is the information reliable? For example, a cell phone service provider would likely use SMS with its digital cell service users. This way, the service provider can manage any service level agreement (SLA).

• If previously collected information is not reliable enough for one-time password authentication, you can register users. The online registration process allows authenticated users to enter, validate, and correct their delivery information (email address, voice phone number, and cell phone number), and out-of-band authentication preferences. This also allows users to personalize the way their one-time password is delivered to them.



• If you are using email delivery of one-time passwords, you can also send details of the requested transaction with the OTP. This allows the user to confirm the transaction details before authenticating. You can configure Entrust IdentityGuard so that, when the user authenticates, a transaction receipt is returned. The returned transaction receipt may be signed, depending on how the policies are set.

Table 9: Out-of-band authentication advantages and considerations

Advantages • It is effective at guarding against attacks such as man-in-the-middle attacks, where a legitimate session may be used to piggy-back fraudulent transactions.

• It helps defeat man-in-the-browser attacks by providing transaction details instantly to users for review and confirmation — all in an easy-to-use approach.

• It can use channels that already exist, including SMS to a cell phone or email to a computer or mobile device. These channels allow the user to confirm a particular transaction using a channel already registered with the organization.

Considerations • When sending the OTP, ensure that you also provide a context as to what the user is getting the password for.

• Consider the sensitivity of the transaction details, as users may not always delete the message immediately, and it may be sent unprotected.

• The expiry time for the OTP should balance your need for security and the amount of time it would take for a user to receive your message and enter the password.

• The number of OTPs a user is allowed should be carefully balanced against the user’s need for authentication while out of delivery range. The more valid passwords available in emails or on cell phones, the worse the damage if the message is intercepted.




• If you are sending several passwords at one time, and the user is storing them for later use, there is a small risk the passwords could be seen. Ensure that you have a process in place to help remind users to safeguard their messages, whether email, or text messages, to avoid unauthorized users getting access to them.

One-time password delivery systemsEntrust IdentityGuard, straight out of the box, can generate and deliver one-time passwords through email, SMS (text) message, or through automated voice calls



62

using Authentify. You can also develop your own out-of-band (OOB) delivery methods using Entrust’s programming environment. See Entrust IdentityGuard Programming Guide for the Java Platform for more information.

In a typical user registration process, your application should ask for an email address and one or more phone numbers (home, work, cell). Once you have contact information, your application can deliver a one-time password by email, by text message to a cell phone, or by an automated voice message to a standard phone or cell phone. If you have developed your own custom OOB delivery method, you can register users with the appropriate contact information, and configure Entrust IdentityGuard to automatically generate and deliver OTPs using your custom delivery method.

For an automated voice message, you must purchase the service from a third-party service, such as Authentify®. For information, visit http://www.authentify.com. For delivery by email or a text message (SMS) to a cell phone, you can use Entrust IdentityGuard to send the one-time password to one or more numbers.

Certificate authenticationThere are two ways to use certificate authentication. You can use certificate authentication as one of the credentials checked during risk-based authentication, or explicitly, by checking the certificate after first factor authentication is successful.

You load Certification Authority (CA) certificates and user certificates into Entrust IdentityGuard and assign certificates to each user.

Table 10: Certificate authentication advantages and considerations

Advantages • Whether you are using certificate authentication through RBA, or as explicit second-factor authentication, it is invisible to the user—the user does not have to remember codes or passwords, or carry grid cards or tokens.

• You can leverage previous interactions between the user and your organization, and investments in PKI technology such as Entrust Authority Security Manager and Entrust Entelligence Security Provider.

• You can easily renew a user’s credentials by updating the certificates, or cancel a user’s access by revoking a certificate or by making it inactive.



Considerations • You must buy certificates or set up a Certification Authority. Entrust Managed Services can help by acting as your Certification Authority and supplying certificates.

• If you use explicit certificate authentication, the application you use must support cryptographic capabilities and a client with access to a private key for use in signing Entrust IdentityGuard challenges.



Table 10: Certificate authentication advantages and considerations (continued)



64

Mutual authentication methodsYour organization needs to have confidence in the user’s identity. Likewise, users must be confident that they are transacting with their organization or intended online site, and not a fraudulent organization or spoofed site. Mutual authentication provides a way for your organization and your users to prove themselves as legitimate. Entrust IdentityGuard provides several mutual authentication methods.

Mutual authentication works as follows:

1 The user completes first-factor authentication successfully.

2 Entrust IdentityGuard presents the user with an authentication challenge.

3 The challenge presents an image or information to the user that only the valid site could have.

4 The user recognizes the image or information, and responds to the challenge.

5 Entrust IdentityGuard validates the entered values and authenticates the user.

Mutual authentication is also called organization authentication. The following options are available:

• “Grid serial number or grid location replay” on page 64

• “Image and message replay” on page 65

Grid serial number or grid location replayGrid authentication not only provides a secure, low cost and easy way to authenticate users, it also includes built-in mechanisms for mutual authentication.

• Each grid card or passcode list has a unique serial number that is known only to the user and the organization that issued it. During login, you can display this number to the user before prompting for second-factor authentication.

Before entering a password or grid challenge response, users confirm that the serial number displayed on the screen matches the one on their grid card or list. If it does, users can be confident they are accessing the legitimate site.

• Another mechanism available with the grid card is to replay or show specific grid coordinates. That is, you tell users what values are in specific cells on their grid cards. This confirms that you know the grid’s contents and, therefore, you must be legitimate.

Table 11: Grid serial number and location replay authentication advantages and considerations

Advantages • Helps users determine if they are at a valid site before they provide sensitive authentication data.

• Easy to use when grid authentication is enabled.



Image and message replayAnother replay method supported by Entrust IdentityGuard is image and message replay. As part of the registration process, the user selects an image from a gallery and enters a custom image caption. During future logins, the user is shown the selected image and their caption, as shown in Figure 15 on page 65.

Figure 15: Choosing a custom image and caption

Considerations • It requires two-step authentication (See “Grid authentication” on page 51 for more information on two-step authentication).

• You can take additional security measures to make this information difficult to harvest. For example, you can conceal entries by avoiding machine-readable characters; that is, display them as images instead of text.




• Microsoft Windows desktop

Table 11: Grid serial number and location replay authentication advantages and considerations (continued)



66

You can provide your own collection of images for users to choose from, you can allow users to upload their own images, or you can make use of the image collection available from Entrust TrustedCare website.

Whatever source users choose their image from, it will be familiar to them. Image and text replay makes it easy for users to know they are on a legitimate site.

Table 12: Image and text replay authentication advantages and considerations

Advantages • Allows a user to determine the site’s legitimacy.

• Not dependent on a specific authentication method.

Considerations • Plan for image data size implications because images require lots of storage space. Images in your collection should be highly optimized and limited in size to manage space requirements in the Entrust IdentityGuard repository.

• Have many images available and let the users choose an image they identify with.

• If you decide to allow users to upload their own images, take special care to manage the amount of disk space budgeted for this feature. Entrust IdentityGuard includes policy settings for a maximum file size that you can set to ensure that users do not upload high-resolution images. Your organization can also deploy a conversion utility to convert high resolution images into an appropriate size (both file size and pixel size).




Machine authenticationMachine authentication provides validation of a user’s computer to secure the user against a variety of threats when users usually access their accounts from the same computer. It allows for seamless authentication without any noticeable impact on the user experience. Machine authentication can also be set up as a part of your risk-based authentication strategy.

To establish the computer identity, your application generates at least one of the following (as specified by Entrust IdentityGuard policy):

• Machine tag. A machine tag is stored in a persistent object (such as a cookie or a flash object) in the user’s Web browser. A machine tag includes at least one of the following.

– machine nonceThis is an arbitrary number generated only during machine registration.

– sequence nonceThis is a number generated each time the machine is authenticated. A sequence nonce ensures that the machine secret is only valid until the next login attempt. The sequence nonce increases security by preventing an attacker from authenticating with an older version of the machine secret.

• Machine fingerprint.

This is a collection of machine data (called application data) specific to the user’s computer, such as the browser version or operating system. The application provides the machine fingerprint each time the user attempts to authenticate.

Note: If the application does not generate a machine nonce, then the application must provide machine fingerprint data.

After generating a machine tag or machine fingerprint (or both), Entrust IdentityGuard stores a copy of the information in the repository as a machine secret.

For maximum security, it is recommended that your application generate both a machine fingerprint and a machine tag (with both the machine nonce and sequence nonce).

If your user machines do not allow persistent objects (such as cookies or flash objects) to be stored, your application can provide just the machine fingerprint data. In this case, it is recommended that the application collect as much application data as necessary to differentiate between similar computers.

Using machine fingerprints alone provides a lower level of security than using machine tags, especially in homogenous environments. When all or most of the users in your organization use the same software, with the same options, and the same version numbers, the machine fingerprint is less likely to be unique for each user. In



68

this case, it is strongly recommended that you use persistent objects such as cookies to uniquely identify the user logging in.

The recommended algorithm for the use of machine secrets is to use persistent data whenever possible, and machine fingerprints when storing cookies or flash objects is not possible is:

• If cookies are enabled, then store cookies

• If cookies are not enabled, then store flash objects

• If cookies and flash objects are not enabled, then provide fingerprint data

Computer registration processThe computer registration process is similarly performed for all computers a user wants to register. In Figure 16, selecting Remember me on this machine sets machine authentication into action.

Figure 16: Login page with machine authentication

During subsequent logins:

1 The application retrieves the machine tag and regenerates the machine fingerprint.

2 Entrust IdentityGuard compares the machine tag and machine fingerprint to the machine secret stored in the repository.

3 If the machine tag and machine fingerprint match the machine secret, Entrust IdentityGuard authenticates the user.

4 The application changes the sequence nonce and Entrust IdentityGuard stores an updated version of the machine secret in the repository.

Entrust IdentityGuard’s machine authentication provides protection for users even if they have had other authentication data stolen by attackers. Because it is unlikely that



an attacker would enter the stolen credentials from the user’s computer, the machine authentication fails and the attacker cannot obtain access.

Sources of machine fingerprint dataThere are several ways to create a fingerprint of a particular computer. The choice depends on the method chosen to gather fingerprint data.

Basic Web browser without client-side softwareThis requires a Web browser only. From the user’s perspective, it is the least invasive method of gathering the information for a machine fingerprint.

Your program needs to set a cookie within the browser for subsequent authentication comparisons of the user’s machine fingerprint. This may not always be possible; some users set their browsers so that cookies cannot be saved.

There are two ways of gathering data from a Web browser without requiring client-side software. You can use the browser Get request or JavaScript.

Through a Web browser Get request, the application can identify a browser using the HTTP headers present in the browser’s request to the server. Unfortunately, all data returned is quite predictable, even to an attacker who has never seen a particular browser’s request. Figure 17 shows a sample Get request.

Figure 17: Sample browser Get request

GET /cgi-bin/inputdump.exe HTTP/1.1

Accept: */*

Accept-Language: en-us

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: anyserver.anybank.com

Connection: Keep-Alive

Cookie: intranetredirectURL=; GA_SHOW_TABS=; LASTSITE=intranet

Due to the predictability of standard Get requests from a browser, it is recommended that you do not use these fields on their own. Some fields (such as user-agent) may be useful as part of a broader machine fingerprint. Use other methods described in this section to create a unique machine fingerprint.

Instead of Get requests, your Web application can use standard JavaScript calls to gather information. This involves a minor modification to the application’s login page to collect the wider range of data needed for the machine fingerprint. All the following pieces of information are available through standard Javascript calls without requiring any client-side software.



70

Note: The properties in Table 13 were collected using JavaScript on an Internet Explorer browser running on Windows. Similar properties are available on other browsers, but the names and values may be different.

Table 13: General properties

Property Value

navigator.appCodeName Mozilla

navigator.appName Microsoft Internet Explorer

navigator.appMinorVersion ;SP2;

navigator.cpuClass x86

navigator.platform Win32

navigator.systemLanguage en-us

navigator.userLanguage en-us

navigator.appVersion 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

navigator.userAgent Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

navigator.onLine true

navigator.cookieEnabled true

screen.availHeight 1170

screen.availWidth 1600

screen.bufferDepth 0

screen.colorDepth 32

screen.deviceXDPI 96

screen.deviceYDPI 96

screen.fontSmoothingEnabled true

screen.height 1200

screen.logicalXDPI 96

screen.logicalYDPI 96

screen.updateInterval 0



Note: The properties in Table 14 and Table 15 show just a portion of the MIME and plug-in information available. They were collected using JavaScript on a Firefox browser running on Microsoft Windows. Similar properties are available on other browsers, but the names and values may be different.

Property Value

navigator.mimeTypes[0].description Mozilla Default Plug-in

navigator.mimeTypes[0].suffixes *

navigator.mimeTypes[0].type *

navigator.mimeTypes[1].description Java

navigator.mimeTypes[1].enabledPlugin. filename

NPOJI610.dll

Property Value

navigator.plugins[0].description Default Plug-in

navigator.plugins[0].filename npnul32.dll

navigator.plugins[0].length 1

navigator.plugins[0].name Mozilla Default Plug-in

navigator.plugins[1].description Java Plug-in 1.5.0 for Netscape Navigator (DLL Helper)

Given the wide range of information available, some of which may be too common to be useful, it is recommended that organizations consider the use of a combination of elements gathered through JavaScript such as:

• browser version

• browser plug-ins present

• browser language being used

screen.width 1600

Table 14: MIME properties (partial list)

Table 15: Plug-in information (partial list)

Table 13: General properties (continued)

Property Value



72

• browser platform (user’s operating system)

• screen size of user’s computer (height and width)

• screen color depth

Basic Web browser with client-side softwareYou can deploy signed Java applets or ActiveX controls that leave the Java sandbox and allow the applet to access the system directly. This involves the user seeing and accepting security notifications on a regular basis. While more secure, it is less than ideal for large-scale deployments. However, there may be instances where this is the best practice since it allows organizations to gather more detailed physical machine data for use in a machine fingerprint.

Elements that could be gathered in this scenario include:

• media access control (MAC) address of the user’s Ethernet card

• exact operating system (OS) information including the service pack and patch level

• system information including native byte order and number of available processors

• hardware information (manufacturer, model, version, and so on) of various hardware devices (network card, video card, hard drive, CD reader/writer, processor type)

• CPU processor ID (if enabled)

• user information (account name and home directory)

You can combine these elements with other available elements to create the machine fingerprint.

Web application (server-side)You can augment the information available through JavaScript and client-side software with data available from the Web application. Figure 18 shows information gathered by a simple server-side CGI.

Figure 18: Sample Web application data

HTTP_USER_AGENT=Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

HTTP_ACCEPT=text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

HTTP_ACCEPT_LANGUAGE=en-us,en;q=0.5

HTTP_ACCEPT_ENCODING=gzip,deflate

HTTP_ACCEPT_CHARSET=ISO-8859-1,utf-8;q=0.7,*;q=0.7



HTTP_KEEP_ALIVE=300

HTTP_CONNECTION=keep-alive

HTTP_COOKIE=LASTSITE=anybank; intranetredirectURL=https%3A//anyserver.anybank.com/download/cnbc.htm; GA_SHOW_TABS=0%2C1%2C2%2C4

REMOTE_ADDR=10.4.132.9

REMOTE_PORT=1294

Much of this information is derived from the HTTP headers in the Get request (see Figure 17 on page 69). This list includes a port and IP address for the user. Port information may change each time and is not a useful property for a machine fingerprint. You can also use a user’s IP address to look up geolocation information.

Entrust IdentityGuard can store additional application data specified by your organization, including data that may be gathered with standard APIs through external data sources. (For example, geolocation services can estimate the geographic location of the user based on the IP address of the PC.)

Table 16: Machine authentication advantages and considerations

Advantages • It provides users with a seamless login experience.

Considerations • Determine whether users ever access your site through a public computer (such as from a library). Using machine authentication on public computers is a security risk and is not recommended.

• Determine how many machine secrets users can have. Users may have more than one machine secret if they access your site from more than one computer. For example, a user may access your site from a work computer and from a laptop.

• Determine whether your application will generate a machine tag or machine fingerprint, or both.

• Determine how to obtain the machine information (depending on the browser type, a client-side application, and so on). See the Entrust IdentityGuard Programming Guide for more information.

• If generating machine fingerprints, determine what application data you want to collect.

• Determine how many elements in the machine fingerprint must successfully match the machine secret for successful authentication.


For example, if one of the elements is the browser version and in a subsequent authentication that version has changed (the user upgraded the browser), it may still make sense to allow that user access.



74

Risk-based authenticationThere are situations in which you want to present users with an extra authentication challenge or reject the users outright for security reasons. Alternatively, you may want to automatically authenticate users who pose no risk.

Setting risk policiesYou can set two risk assessment policies—normal and enhanced—in Entrust IdentityGuard that determine how your application reacts in the five risk scenarios below:

1 A user logs in from a different computer than usual and machine authentication fails. For more information, see “Machine authentication” on page 67.

2 A user logs in from an IP address that is not in the user’s location history list (IP addresses the user authenticated from recently). For more information, see “IP geolocation” on page 75.

3 A user logs in from two separate geographic locations in a suspiciously short period of time. This is known as a velocity test. For more information, see “IP geolocation” on page 75

4 A user logs in from an IP address that is on the IP blacklist. For more information, see “Blacklists” on page 76.

5 A user logs in from a country that is on the country blacklist. For more information, see “Blacklists” on page 76.

6 A user logs in with a certificate that is invalid. For more information, see “Certificates” on page 75.

For example, your normal security policy might reject the user in the case of 4 and 5, and issue an authentication challenge in the other three cases. In comparison, the enhanced security policy might reject the user in all cases but 1 and 2.

Setting authentication policiesFor any user not rejected by the risk policies described above, you can set other policies that determine when those users can enter a site without an authentication challenge. Some possibilities are:

1 If one of machine authentication, certificate authentication, or IP authentication pass, automatically authenticate the user.

2 If just IP authentication passes, automatically authenticate the user.

3 If just machine authentication passes, automatically authenticate the user.

4 If just certificate authentication passes, automatically authenticate the user.

5 If both IP authentication and machine authentication pass, automatically authenticate the user.



6 Always present the user with a challenge.

The challenge or challenges presented to the user can be any of those described previously in this chapter: grid, passcode list, token, knowledge-based (question-and- answer) and one-time password.

IP geolocationEntrust IdentityGuard includes a mechanism to determine the approximate geographical location of the IP address of any user who attempts to access your site. The location data consists of the country, region, city, Internet service provider (ISP), latitude, and longitude.

With this data, Entrust IdentityGuard determines if the user passes your risk and authentication policies.

• Compare the current location with the list of expected locations. If there is a match, the user passes the expected location test.

• Compare the current location with the list of locations previously associated with the user. If that location matches one on the list, the user passes the location history test.

• Compare the current location with the last location associated with the user. If the user changes locations faster than physically possible, the user fails the velocity test. For example, if the user logs in from Toronto at 10:00 a.m. and then logs in from New York a few minutes later, it is likely that one of the logins is not legitimate.

• Compare the current location with all locations on the IP and country blacklists. If a user's location is on a blacklist, the user is rejected.

CertificatesEntrust IdentityGuard allows you to authenticate users by the certificates they have loaded into their Entrust IdentityGuard account. If the application determines that the certificate available at the time of authentication is a valid one, Entrust IdentityGuard authenticates the user.

A certificate can also be loaded into a user account after the user successfully answers a second-factor challenge.

During risk-based authentication, the certificate is presented to Entrust IdentityGuard by the user. If the certificate is found to be valid, and the other RBA conditions are met, the user is authenticated.

A certificate is considered valid if:

• It is registered to the user.

• It is within its validity period.



76

BlacklistsThrough the Administration interface or the master user shell, you can review and update blacklists containing country codes and IP addresses.

You can have multiple country blacklists. This way, you can apply different lists to different groups of users. A country blacklist consists of the two-character Internet domain codes assigned to each country. The default list included with Entrust IdentityGuard contains A1 codes, which are addresses that belong to anonymous proxy services, and A2 codes, which relate to satellite-based Internet providers that conceal the country of origin.

You can have a single, system-wide IP blacklist that applies to all users. To keep the list compact and easy to maintain, each entry you add to the blacklist can specify a range of IP addresses. For example the entry “100.1.1.1 100.1.1.10” represents 10 IP addresses. (The blacklist supports only version 4 IP addresses.) By default, the IP blacklist has no entries.

Table 17: Risk-based authentication advantages and considerations

Advantages • Provides a flexible risk-assessment mechanism.

• Lets you block users from high-risk Internet domains or geographic locations.

• Lets you match the authentication methods to the risk level of the user or groups of users.

• Lets you automatically authenticate low-risk users.

Considerations • The IP location data relies on third-party data sources. Entrust IdentityGuard supports MaxMind. (For more information, visit http://www.maxmind.com.) You can customize the interface to support other data providers; contact “Entrust Professional Services”.

• You need to update IP location data on a regular basis—at least monthly. Downloads are available on the Entrust TrustedCare Online Web site.

Note: You must have a subscription to Entrust Open Fraud Intelligence Network (OFIN) to be able to update the Maxmind data.

• Determine how many entries you want for the location history list.

• Set a standard for the velocity test.

• Make sure your Web application can supply valid IP addresses to Entrust IdentityGuard.

• If you are using certificates, purchase and distribute certificates.




Table 17: Risk-based authentication advantages and considerations (continued)



78

Temporary PIN authenticationIn situations where the user does not have their grid card, token, soft token, or passcode list, you can issue a temporary PIN, either for a specific number of uses or for a limited period of time. Examples of this situation include lost grid cards or tokens, or a newly registered user waiting for their grid card or token to arrive. Temporary PINs are only available for grid card or token authentication.

Temporary PINs are issued with limits on the number of uses and expiry dates to limit exposure to attacks. These values are configured by administrators, who need to take into consideration how long it will take to deliver a replacement grid card or token to the user.

Table 18: Temporary PIN authentication advantages and considerations

Advantages • It allows users to log in even if they have forgotten or lost their grid card or token.

Considerations • It is only available if using token or card authentication (either grid or passcode list).

• It requires policy considerations such as: expiry mode (either time or use-based), minimum length, characters to use, character replacements, challenge size, and automatic deletion when a user begins using their grid card or token.

• You should only use this method as a temporary second-factor authentication solution and not as a permanent second-factor authentication solution.




Transaction verificationTransaction verification is an optional feature available for use with Entrust IdentityGuard Mobile and Entrust IdentityGuard Self-Service Module. When enabled, users with Entrust IdentityGuard Mobile are sent the details of a pending transaction they started on your Web site—a money transfer, for example. Users are then given three options: confirm the transaction, reject it, or mark it with 'Concern' in their transaction history. If users choose to confirm the transaction, Entrust IdentityGuard Mobile generates a confirmation code (which is actually an OCRA digital signature of the transaction details). The user then enters this confirmation code into your Web site to confirm the transaction.

By having a confirmation notice sent to a secondary device, man-in-the-browser attacks are mitigated.

Transaction verification has two main sub-features:

• transaction notifications—these are alerts that indicate to the mobile user that a pending transaction is waiting for them. This is an optional feature of transaction verification.

• transaction history—a history of transactions and their corresponding details are kept by Entrust IdentityGuard Mobile for easy browsing. This is a standard feature of transaction verification.

For details on configuring transaction verification, see the Entrust IdentityGuard Self-Service Module Installation and Configuration Guide.

A record of each transaction is kept on the mobile device, so users can review them as needed.

To verify a transaction

1 A user performs a high-risk online transaction such as a large transfer of money from one account to another.

2 The transaction is high-risk, so the transaction details are sent to the user’s mobile device asking them to confirm the transaction. Optionally, the user is made aware of the transaction through a transaction notification, which is accompanied by a vibration or ring tone. The notification is sent using the notification service, a Web service hosted by Entrust.

3 On their mobile device, the user reviews the transaction details (such as the relevant accounts and amount being transferred) and then selects OK, which confirms that the transaction is legitimate.

The user also has the option to Cancel the transaction if they made a mistake. They can also click Concern, which cancels the transaction and marks it with an exclamation mark in their transaction history. Users choose Concern if they suspect that the transaction is fraudulent.



80

4 If the user selects OK to confirm the transaction, then a confirmation code is generated and displayed by the Entrust IdentityGuard Mobile application.

5 The user enters the confirmation code onto the banking Web site. If the code is correct, the transaction is completed at the bank. Otherwise, the transaction is terminated. In both cases, a record of the transaction is kept on the mobile device.

For details on how to confirm transactions with Entrust IdentityGuard Mobile, see the Entrust IdentityGuard Mobile User Guide.



Figure 19: Transaction verification with a notification



82

Using personal verification numbersFor additional security, you can require a user to enter a personal verification number (PVN) during an authentication challenge. For example, when a user enters grid coordinates, you can also prompt for their PVN to validate the grid card user.

A PVN can be used with a card (grid or passcode list), token, soft token, temporary PIN, or one-time-password authentication challenge.

Each user can have just one PVN. The PVN is a numeric value whose length is set by policy. Users can pick their own PVNs or administrators can auto-generate random PVNs and assign them to users.



3

Smart credential authentication

Entrust smart credentials provide strong authentication of user identities before granting access to networks, facilities, devices, and more. Entrust smart credentials can be placed on various form factors, such as smart cards, USB tokens, and mobile devices, and use the most advanced technology to increase security, functionality, and usability.

Entrust’s multipurpose smart credentials help provide true physical and logical access convergence. For additional flexibility, smart cards may be combined with an additional authentication mechanism—such as grid authentication or digital certificates—that may be seamlessly embedded on or within any smart credential.

Entrust IdentityGuard provides you with the capability to capture and store sensitive biometric data on the smart credential using a secure, tamper-proof method. Biometric data cannot be copied or modified without detection. The sensitive information cannot be released unless the cardholder provides a PIN and the card is read by a trusted card reader.

Figure 20 shows an example of an Entrust smart credential.

Figure 20: Sample Entrust smart credential

83

84

Table 19 on page 84 lists the advantages and considerations of smart credential authentication.

Table 19: Smart credential authentication advantages and considerations

Advantages • Can be combined with an additional authentication mechanism—such as grid authentication or digital certificates—that may be seamlessly embedded on or within any smart credential.

• Entrust smart credentials are based on the open Java Card platform. Java Card technology is one of the most versatile, interoperable platforms for smart cards and secure USB tokens available.

• You can leverage previous interactions between the user and your organization, and investments in PKI technology such as Entrust Authority Security Manager and Entrust Entelligence Security Provider.

• You can easily renew a user’s credentials by updating the certificates, or cancel a user’s access by revoking a certificate or by making it inactive.

Considerations • You need to determine how to roll out smart credentials and train users.

• Smart credentials are not as cost efficient to buy, maintain, and renew as other methods (such as grids). Entrust smart credentials are more cost efficient than smart credentials from other vendors.

• You must buy certificates or set up a Certification Authority. Entrust Managed Services can help by acting as your Certification Authority and supplying certificates.

Deployment type • Microsoft Windows desktop

IdentityGuard 10.0 Deployment Guide Document issue: 1.0Report any errors or omissions


4

Planning your deployment

This chapter discusses items to address prior to, or during, the deployment of Entrust IdentityGuard.


• “Planning: initial considerations” on page 86

• “Planning administrative tasks” on page 91

• “Planning user requirements” on page 93

• “Group requirements” on page 98

85

86

Planning: initial considerationsThis section identifies, at a high level, both the technical and nontechnical aspects that need to be addressed for a successful deployment. These aspects can be categorized into the following five areas:

• authentication methods

This refers to the authentication methods supported by Entrust IdentityGuard and that your organization requires to verify user identities. Examples include considering the requirements for second-factor and mutual authentication, and how to implement the methods with your existing authentication structure.

See “Authentication methods” on page 41.

• policies and practices

This refers to the specific security policies supported by Entrust IdentityGuard and the practices used by your organization to implement these polices. Examples of policies for Entrust IdentityGuard include the size of the grid or passcode list, the length of a challenge, the number of authentication factors, the use of a personal verification number (PVN), the inclusion of blacklists, and the number of incorrect attempts before lockout.

See “Entrust IdentityGuard policies” on page 87.

• people

This refers to the personnel required to deploy, operate and support Entrust IdentityGuard.

See “People” on page 88.

• architecture and technology

This refers to the technical aspects of supporting Entrust IdentityGuard, such as the networking environment, operating systems, hardware and software, and application integration. Examples include the environment in which Entrust IdentityGuard is deployed, and the applications that Entrust IdentityGuard protects.

See “Entrust IdentityGuard components” on page 29 and “Entrust IdentityGuard baseline architectures” on page 175.

• operations

This refers to the ongoing operational aspects of Entrust IdentityGuard and the procedures needed to support, administer, and operate Entrust IdentityGuard. Examples include the initial deployment of grid cards or tokens, and the distribution and activation of replacement grid cards or tokens.

See “Operations” on page 89.




• “Entrust IdentityGuard policies” on page 87

• “People” on page 88

• “Operations” on page 89

Entrust IdentityGuard policiesOrganizations generally have existing polices and practices around the identification and authentication of users. The processes used for user identification and authentication to the existing application will apply to Entrust IdentityGuard configuration and deployment.

Entrust IdentityGuard, through its policy set, defines the permissible behavior of users, administrators, and authentication methods. When deploying an Entrust IdentityGuard system, you need to decide what types of policies you need and how many you need based on user and authentication requirements.

Policies are associated with groups in Entrust IdentityGuard. This means you can create different policies for your system, based on the different requirements of different user groups (“Group requirements” on page 98).

For example, Entrust IdentityGuard uses policies to determine:

• password rules for administrators when logging into the administration interface.

• what grid cards should look like (for grid authentication).

• how users interact with Entrust IdentityGuard (for example, how many invalid password attempts users can make before being locked out, and what authentication methods are available to them).

• when to include a PVN with a challenge.

• temporary PIN rules (for grid, passcode list or token authentication only—you can assign a temporary PIN to a user when a grid card or token is lost or forgotten).

Organizations should:

• Set up security policies that contain statements regarding appropriate user security measures, such as keeping grids, passcode lists, or tokens out of sight when not in use and memorizing PVNs, answers, and other information.

• Train users on the importance of protecting their Entrust IdentityGuard authentication information and keeping it confidential. This includes emails, mobile telephones, and voice mail that may include one-time passwords. This can be done through security awareness training and internal communications.

87Planning your deploymentReport any errors or omissions


88

• Consider the requirements for identity verification during enrollment and for grid card and token replacement. These requirements will be driven primarily by the business value of the applications being protected with the Entrust IdentityGuard authentication methods. Choosing to add Entrust IdentityGuard authentication to the application indicates that there is a substantial value involved.

For information on specific policies, see the Entrust IdentityGuard Server Administration Guide.

PeopleAs with any system, Entrust IdentityGuard’s deployment and ongoing operation requires the participation of people from different parts of your organization. Although many people are required only on a part-time basis, identifying them and communicating their roles and responsibilities early in the planning process can help avoid delays later.

Table 20: People required for the deployment and operation of Entrust IdentityGuard

Person or people Job description

Overall project manager (recommended)

Act as a single point of contact for the project and have the authority to secure additional resources.

Technical lead Bring knowledge of the organization’s technical environment to the project. Throughout deployment (along with other personnel), obtain the necessary knowledge to support the production implementation into the operational phase.

Directory administrator Administrate the directory if integrating with an LDAP-compliant directory.

Database administrator Administrate the database if integrating with a JDBC-compliant database or if using a database to store Entrust IdentityGuard audit information.

Network and systems administrators

Provide support during the planning and installation phases.

Application development personnel

Provide support for the application integration.

Operations personnel Provide support for the operational requirements after deployment.

Customer Support and Help Desk personnel

Integrate support services for Entrust IdentityGuard into the existing support mechanisms.

Hardware procurement personnel

Obtain any necessary hardware (such as servers, grid cards, and tokens).



OperationsOperation planning encompasses back-end operational aspects such as server administration and operations, backup and recovery, and maintenance and upgrades. It also includes the systems required for customer support. Entrust IdentityGuard is added to an existing application infrastructure; in most cases, only minor updates to existing system administration procedures are required.

Entrust IdentityGuard maintains log files to assist administrators in troubleshooting activities. For more information on these logs, see the Entrust IdentityGuard Server Administration Guide.

Backup and recoveryUpdate your regular backup and recovery procedures with new information about the Entrust IdentityGuard Server and its operation.

• Through the Entrust IdentityGuard Configuration Panel (Windows) or the backup and restore scripts (UNIX), you can create full or partial backups of primary and replica Entrust IdentityGuard Servers, and you can restore those servers. You can also use the backup and restore features to move your Entrust IdentityGuard configuration to a different platform—UNIX to Windows, or Windows to UNIX.

• If Entrust IdentityGuard is integrated with an existing directory or database, repository backup and recovery will be handled through the existing processes for these repositories.

• If a new repository is implemented for Entrust IdentityGuard, backup and recovery processes should be established and documented in accordance with your organization’s existing standards for data backup.

• Update your organization’s disaster recovery plan to include Entrust IdentityGuard.

The Entrust IdentityGuard Installation Guide provides information about backing up Entrust IdentityGuard Server configuration files, along with information about recovery steps.

System support personnel

Carry some of the responsibility for the ongoing support of Entrust IdentityGuard.

Note: These people may be representatives from other groups in your organization.

Table 20: People required for the deployment and operation of Entrust IdentityGuard

Person or people Job description



90

System monitoringEntrust IdentityGuard operation generates a series of audit messages that can be written to a file or stored in a database. You can also view the audits in the Administration interface.

The audits should be examined periodically as a way of understanding the kinds of activities that are most common, and as a way to monitor system health. There are three types of audits written: INFO, WARNING, and ERROR. In the WARNING and ERROR cases, messages are also written to the system logs.

If you choose to send selected audit data to a database, either your Entrust IdentityGuard database, or a separate database that you configure for audit data, you can generate scheduled or on-demand audit reports from the database. If your Entrust IdentityGuard installation uses an LDAP repository, you must configure a database for storing the audits if you want to store them or run reports containing audit records.

As an added benefit, your Entrust IdentityGuard installation can be configured to send selected audits as traps to your SNMP manager. This allows your support staff to be notified immediately of system or performance problems, improving their response time.

Other precautionsLocate the Entrust IdentityGuard Server and related systems in a secure facility designed and constructed to support the hosting of IT systems infrastructure. Such hosting facilities are typically equipped with perimeter security barriers, surveillance, air conditioning, uninterrupted power supply and fire protection. Implement physical access controls to ensure that only those authorized to perform operations or support services are allowed to enter the Entrust IdentityGuard region, which may be a separate room or a lockable cabinet.

Depending on your organization’s approach to deploying applications into production, additional implementations of Entrust IdentityGuard into test or staging environments may be required.



Planning administrative tasksBesides the people required to deploy Entrust IdentityGuard (see “People” on page 88), you need to plan for people who will administer Entrust IdentityGuard and its users.

You must assign the following Entrust IdentityGuard roles:

• Master User 1, Master User 2, and Master User 3. Assign a different person to each of these three roles. These people are required during the initial installation of Entrust IdentityGuard and after an upgrade or restore. Administrators perform most other duties.

• One or more administrators. Assign administrative privileges to people in your organization so that they can manage the Entrust IdentityGuard system and users. You should have one administrator super user, who can do everything, and other administrators to manage groups and roles, configure Entrust IdentityGuard, and manage policies.

Note: In Entrust IdentityGuard, any user can become an administrator if you assign that user one or more roles.


• “Assigning master users” on page 91

• “Assigning administrators” on page 92

Assigning master usersAssign one of the master user roles to the deployment project technical lead. Master users can perform the following activities using the Entrust IdentityGuard master user shell:

• initialize the system

• export the master keys

• create and manage administrators

Consider the following when assigning the three master user roles:

• The master user role allows extensive administrative capabilities. Assigning staff to these roles should comply with existing policies on administration staff.

• Identify who your master users will be before installing Entrust IdentityGuard. Ensure the master users are scheduled for the installation and that they have a password ready. During the initialization process, Entrust IdentityGuard prompts the three master users to enter their passwords for the user names Master1, Master2, and Master3. The passwords must be a



92

minimum of eight characters in length, and contain upper and lowercase characters and a numerical value.

• For security reasons, master users do not have administrator privileges within the Administration interface. An administrator who is also a master user requires two identities. See the Entrust IdentityGuard Installation Guide and the Entrust IdentityGuard Server Administration Guide for more information.

• Once you identify the master users, provide appropriate training. Update existing documents (such as operational procedures, administration guides, and training materials) or create new documentation as required.

Assigning administratorsAdminister Entrust IdentityGuard and its users through the Administration interface. This interface allows administrators to manage Entrust IdentityGuard policies, groups, users, grid cards, tokens, configuration, and so on, and to handle day-to-day interaction with the users (for example, requests for temporary PINs). You can enter user information individually or by importing a file of user IDs.

Consider the following when determining the number and levels of administrators you require:

• Each administrator is assigned a particular role or set of roles, which defines which operations they can perform. Roles include a set of permissions that govern what actions an administrator can perform.

For example, you can restrict an administrator who works at your Help Desk to

– reset user accounts once they’ve been locked out– manage temporary PINs – view user account information For more information about roles, see the Entrust IdentityGuard Server Administration Guide.

• Administrators access the administration interface using password authentication. You can optionally add grid or token authentication as well.

• Each administrator is assigned a set of user groups to manage.

• Administrators belong to a group, which determines their policy settings. This group does not have to be a group they manage. See “Group requirements” on page 98.

• The Properties editor gives administrators with applicable permissions to access all Entrust IdentityGuard properties. Only administrators with a very good understanding of Entrust IdentityGuard should be given access to the Properties editor.



Planning user requirementsUsers are separated into different categories:

• the authentication methods you require they use

• how they are accessing your site

• how they are grouped

• the number of user names they have


• “Alias and user ID requirements” on page 93

• “Training users” on page 94

• “Providing services to users” on page 95

• “Locking users out” on page 96

• “Suspending users” on page 97

Alias and user ID requirementsUsers must have a user ID (usually their user name in the first-factor authentication system) and can have one or more aliases (additional user names) so that different applications can share one Entrust IdentityGuard authentication method. For example, one may use a Windows domain user name while another may use the user's email address. Entrust IdentityGuard allows a user to have a single authentication method such as a grid card for authentication to all these applications.

To set this up, an administrator can specify a list of aliases as well as a user ID for a user. When performing authentication or administration operations on the user, your application can return either the user ID or an alias.

A user ID consists of the user name and group name, written in group/username format. For example, if the user’s name is alicel who is in the group gold, the information passed from the application to Entrust IdentityGuard can be in the form gold/alicel. Entrust IdentityGuard processes it as follows:

• If the user ID contains the group name, Entrust IdentityGuard has a unique match and uses the associated user account.

• If the user ID does not contain the group name, Entrust IdentityGuard searches for all users with the given name as their user name or an alias following these rules:

– Search all repositories for all users with the given user name. For an LDAP-compliant directory, look in all search bases.

– If no user entries are found, return an error.– If one user entry is found, use that entry.– If multiple user entries are found, return an error.



94

If you are using groups, it is recommended that client applications send both the group and user name to Entrust IdentityGuard. See “Group requirements” on page 98.

User names and aliases must be unique within a group. For example, two users in the same group cannot use the same alias, even if the alias is used with different applications.

Note: You can change the default behavior of Entrust IdentityGuard so that it enforces unique user names across all groups. In other words, when an administrator (or application) tries to create a user with an existing user name in the Entrust IdentityGuard system, an error is thrown.

If you plan to allow aliases, consider the following:

• Determine all user access points that will be protected by Entrust IdentityGuard.

• If the same user has multiple user names, determine the maximum number of aliases each user requires.

• Ensure that, when dividing users into groups, the user names and aliases are different in each group.

• If you have similar user names and aliases across different groups, ensure that your applications return the user ID in group/username format

Aliases in a consumer deploymentRelated Web applications often use different user IDs for the same person, such as banks with brokerage and credit card divisions. Users typically have different identifying credentials for their bank account, online broker, and bank-issued credit card. In some cases, they have different user IDs for their checking and savings accounts. When the user logs in to the bank’s Web site, users want a seamless interface to all their financial records and transactions. They want to flip between their bank accounts, credit card purchase list, and stock portfolio.

Entrust IdentityGuard allows a user to have a single means of authentication (such as a grid card or token) for all these applications. It permits an administrator to specify more than one ID for a user. This consists of the primary user ID and a list of aliases. When performing authentication operations on users, the users can specify either their user ID or an alias.

Training usersWhen deploying Entrust IdentityGuard, you must train your users to use the new authentication methods and have them register as required. Also, if you have



Microsoft Windows desktop users, they must install the Entrust IdentityGuard Desktop Client for Microsoft Windows.

When planning training for users, consider the following:

• Inform users of Entrust IdentityGuard and your company’s plans for implementation before deployment.

• Create a flash demo or similar video that illustrates how to use the new authentication methods.

• Ensure that the login page that includes the Entrust IdentityGuard challenge is visually clear and uncluttered, with easy-to-navigate help links.

• Educate users on appropriate handling of tokens, grid cards, and PVNs.

The interaction points with the users will vary depending on how the user life cycle management processes are implemented. See “Life cycle management overview” on page 160 for more information.

Providing services to usersAn organization can implement any or all of the following approaches in providing services to their Entrust IdentityGuard users:

• Entrust IdentityGuard Self-Service

Users access an online application to request enrollment to Entrust IdentityGuard, or to request a replacement grid card, token, or soft token. Upon acceptance of the request, one of the following can happen:

– For grid or hardware token authentication, the users are sent an Entrust IdentityGuard grid or token (or pickup instructions) with activation instructions.

– For soft token authentication, users are asked to download the soft token application from Self-Service, or are presented with the information necessary to reactivate their soft token.

– For other authentication methods (such as knowledge-based authentication), the application can automatically enroll the user or replace the user’s authentication data.

• over-the-counter

Users physically visit a Service Desk to request enrollment into Entrust IdentityGuard, or to request a replacement grid card or token. All processes are completed with the user present. This approach is useful during pilot phases where a small number of users (for example, less than 100) are enrolled, and enrollment can be automated in parallel with the pilot.

• help desk



96

Users call your help desk to request a soft token, or other non-physical authentication method. The help desk clerk and end user work together to assign the authentication method.

• administrator-initiated service

An administrator initiates enrollment into Entrust IdentityGuard, or replaces grid cards or tokens, and issues Entrust IdentityGuard authentication data for many users at once using bulk operations.

Locking users outEntrust IdentityGuard includes a locking mechanism that preserves the usability of an authentication method. Users are locked out after a defined number of failed authentication attempts (the default is three). This prevents a brute force attack whereby the attackers keep guessing until they get the correct response.

Each failed authentication attempt, regardless of authentication method, contributes to a cumulative lockout count. For example, if a user has forgotten their password and is locked out, they will continue to be locked out if they try to use their token or grid.

Users can be rejected even before they attempt to authenticate if they fail established risk-assessment policies. See “Risk-based authentication” on page 74.

Preventing brute force attacks through lockoutsTo prevent an attacker from refreshing the challenge (such as question and answer pairings) until they get a challenge that they can answer, Entrust IdentityGuard has two solutions:

• Challenge retention. Entrust IdentityGuard continues to present the same challenge, updating the lockout count on each failed authentication attempt, until the challenge is answered correctly, or the user is locked out.

• Challenge refresh. Entrust IdentityGuard presents a new challenge each time a new one is requested. This behavior might be desirable for question and answer authentication, where a user might have forgotten some of their answers and so wants to refresh to get a new challenge. To prevent an attacker from continually refreshing the challenge until they know the answer, Entrust IdentityGuard can be configured to update the lockout count on each refresh. This limits the number of new challenges that an attacker can receive.

Preventing phishing attacks through challenge timeoutsAs an additional security measure, Entrust IdentityGuard can also limit the lifetime of a challenge. This limit is aimed at preventing phishing attacks, where an attacker will get a challenge, and then through a phishing means, obtain the answer from you. By



having a lifetime, the attacker has very little time to phish for the answer before the challenge expires.

PIN-protection lockoutAside from the authentication lockout discussed above, there is also a PIN lockout for some authenticators, such as soft tokens and the Entrust Pocket Tokens. These authenticators can be configured with a PIN, which if entered incorrectly too many times, causes the user to be locked out of the soft token application or pocket token.

Suspending usersAdministrators with applicable permission can suspend users. Suspended users cannot use any Entrust IdentityGuard authentication method to gain access to your applications.

View suspension as a temporary measure—an action taken while a problem with the user is investigated and sorted out. To disable a user permanently, delete the user.

Users may also be automatically suspended if Entrust IdentityGuard is configured to notice that the user is disabled or expired in the LDAP user repository.



98

Group requirementsEntrust IdentityGuard incorporates the concept of groups into the management of users and policies. Groups are used to subdivide the population of users and administrators into smaller units, where each unit shares a common set of authentication and security policies. See “Entrust IdentityGuard policies” on page 87 for more information.

You can also apply different levels of risk assessment (normal or enhanced) to groups using a policy setting. See “Risk-based authentication” on page 74.

Attention: While you can change a group’s policy settings after the creation of the group, take care not to invalidate pre-existing grid cards or other authentication data. For example, if the grid size is increased from five rows to 10 rows after grid cards have been issued, subsequent challenges might include cell coordinates from the additional five rows that do not exist on the original grid cards.


• “Groups in a consumer deployment” on page 98

• “Groups in an enterprise deployment” on page 98

• “Analyzing your company’s group needs” on page 99

• “Group implementation” on page 100

Groups in a consumer deploymentThere are many ways groups apply to “classes” of users in consumer environments. Credit card holders may be separated into bronze, silver, or gold classifications. Loyalty card users may be separated into regular, special, and elite classifications. The policy for each group can include different authentication methods.

Configure the application to send both the group and user ID to Entrust IdentityGuard. For example, if the user’s ID is alicel who is in the group gold, the information passed from the application to Entrust IdentityGuard should be in the form gold/alicel.

Groups in an enterprise deploymentThere are many ways groups apply to users in enterprise environments:

• how they access your site (Windows desktop users or Web users)

• what privileges they have to sensitive information, and therefore, what authentication methods they require

• functional or geographical similarities



• which resources or applications they access

• how they are administered

For example, a business with offices in Tokyo, New York, London and Ottawa may decide to divide their users into four geographical groups. Within those groups, the business may divide the users further into remote or office employees. Or, as another example, you may want to provide only some users with tokens, and group them accordingly.

Analyzing your company’s group needsCreate a summary of Entrust IdentityGuard groups. Groups affect users, administrators, and authentication data, so consider the following when defining groups:

Table 21: Things to consider when creating Entrust IdentityGuard groups

Considerations Comments

What types of users do you have that require multifactor authentication?

• Do you have users in defined groups connecting to your company through VPN servers?

You will need to enable either the Entrust IdentityGuard Radius proxy or another VPN server authentication method.

• Do you have distinct groups of Windows users that require multifactor authentication when logging in to their computer?

You will need to install and configure the Entrust IdentityGuard client for Windows.

• Do you have users who access your site using a Web portal?

You can put these users in a separate group with mutual authentication enabled.

• Which applications will you create, and what types of users will access each application?

You can group users by the applications they access.

How will you subdivide these groups?

• What sorts of multifactor authentication do these users need?

• Do some users who access your applications require stronger multifactor authentication than others? Do some require step-up authentication?

• Should users be grouped across functions, within departments, or both?



100

Group implementationEntrust IdentityGuard implements groups in the following way:

• Groups are defined for both users and administrators.

• A single group is defined as default using a default flag. This group is used whenever a group is not explicitly defined.

• Grid cards and tokens are associated with specific groups. In order to assign the grid card or token to a user, the user must belong to the same group as the grid card or token.

If your system contains only unique user names, then your client applications do not have to include the group name in user identification requests.

When Entrust IdentityGuard needs to verify a user and the application does not return the group information, Entrust IdentityGuard tries to match the user with the correct group following these rules:

• First search all repositories for all users with the given user name. For an LDAP-compliant directory, look in all search bases. See “Repository” on page 34 for more information on the connection between search bases and groups.

• If no user entries are found, return an error.

• If one user entry is found, use that entry.

• If multiple user entries are found, check if one of those entries is in the default group. If it is, return that entry. If not, return an error.

Note: If you are using groups with VPN users, see the Entrust IdentityGuard Server Administration Guide for more information on how groups are implemented.

How will you administer these groups?

• Will each group have specific administrators?

• Will one central group of administrators administer everything?

• Will some administrators administer multiple groups?

• Will you have different levels of administration? For example, will help desk administrators unlock passwords and assign temporary PINs, and full administrators set up authentication methods, and so on?

Table 21: Things to consider when creating Entrust IdentityGuard groups (continued)

Considerations Comments



5

Deployment considerations

This chapter provides information you should consider when deploying Entrust IdentityGuard in your organization.


• “Application integration” on page 102

• “Application considerations” on page 105

• “Using a Hardware Security Module (HSM)” on page 107

• “Selecting a repository” on page 108

• “Performance testing strategies” on page 111

• “Backing up, restoring, and migrating from one platform to another” on page 113

• “Switching users over to Entrust IdentityGuard” on page 114

• “High availability and disaster recovery” on page 115

101

102

Application integrationYou can integrate Entrust IdentityGuard with many applications, including Web portal applications, remote access applications, Microsoft Windows login, and Entrust IdentityGuard Self-Service. Several of these applications have already been integrated, tested and documented by Entrust with more to be added over time.

For the latest information on integrated solutions, contact Entrust. See “Obtaining technical assistance” on page 18 for contact information.


• “Web integration” on page 102

• “Microsoft Windows integration” on page 103

• “VPN remote access integration” on page 103

• “Wireless Access Portal integration” on page 104

• “Self-Service integration” on page 104

Web integrationThe Entrust IdentityGuard Authentication API is used to retrieve challenge requests and authenticate user responses. It is designed to easily integrate with your existing authentication applications to provide multifactor authentication.

You can create a client application that calls the Authentication API using its Web service, Java Platform, or .NET interfaces to authenticate users. For more information, see the Entrust IdentityGuard Programming Guide for your programming language.



Figure 21: Web integration using Authentication API

Microsoft Windows integrationEntrust IdentityGuard Desktop for Microsoft Windows is a small-footprint client that communicates with the Entrust IdentityGuard Server. It provides strong multifactor authentication to the Microsoft Windows desktop (online, offline and remote) and the network. You can set up integration with Microsoft Windows in two ways:

• for local desktop users (Figure 50 on page 198)

• for remote users (Figure 44 on page 190)

If your deployment includes remote users, you need to add the Remote Access Plug-in. For more information, see “Entrust IdentityGuard components” on page 29.

VPN remote access integrationEntrust IdentityGuard supports integration with remote access VPN devices to provide multifactor authentication. This is accomplished through integration with the Entrust IdentityGuard Radius proxy. The Radius proxy manages communications between a VPN server and a first-factor authentication resource, which can be a Remote Authentication Dial In User Service (Radius) server, a Windows domain

103Deployment considerationsReport any errors or omissions


104

controller, an LDAP-compliant directory, or Entrust IdentityGuard. You then use Entrust IdentityGuard to provide multifactor authentication.

Regardless of the resource you use, the VPN server thinks it is communicating with a Radius server. It is actually communicating with the Entrust IdentityGuard Radius proxy. Figure 39 on page 184 illustrates the integration approach. No changes are required for the VPN client.

With the Entrust IdentityGuard Radius proxy, you can configure some of your VPN servers to use a Radius server and some to use a different first-factor authentication resource. You can direct different groups of users to different first-factor authentication resources. Users who do not exist in Entrust IdentityGuard are authenticated by the first-factor authentication mechanism only.

See the Entrust IdentityGuard Server Administration Guide for details on how to configure the Radius proxy.

Wireless Access Portal integrationEntrust IdentityGuard supports integration with wireless access devices to provide multifactor authentication. This is accomplished through integration with the Entrust IdentityGuard Radius proxy. The Radius proxy manages communications between a wireless access point and Entrust IdentityGuard. You then use Entrust IdentityGuard to provide multifactor authentication.

Regardless of the resource you use, the wireless access point thinks it is communicating with a Radius server. It is actually communicating with the Entrust IdentityGuard Radius proxy. Figure 42 on page 188 illustrates the integration approach.

See the Entrust IdentityGuard Server Administration Guide for details on how to configure the Radius proxy.

Self-Service integrationThe Entrust IdentityGuard Self-Service Module is a Web application available for use with Entrust IdentityGuard. It allows users to perform many Entrust IdentityGuard registration and administration tasks that administrators would otherwise have to perform. For example, through Self-Service users can add their contact information, ask for replacement grids or tokens, or ask to be unlocked.

See “Self-Service architectures” on page 203 for details and network diagrams.



Application considerationsDefine a policy that addresses all the security aspects of the Entrust IdentityGuard authentication data (whether tokens, grids, passwords, or replay information). These security aspects need to be defined as a whole, since changing any one of these aspects affects the overall security of the system. To maximize resistance to attacks, you can do the following to make it difficult to capture second-factor authentication data:

• Implement strong session security using SSL or TLS to protect the transmission of challenges and responses.

• Do not display the challenge values as machine-readable characters.

Machine-readable characters can be easily read by text sniffers and other attacker tools. Consider converting challenges to images instead of text.

• If you are using grid authentication, implement two-step authentication.

In two-step authentication, users must enter first-factor credentials on one screen, then enter the grid coordinates on the second screen. Because the identity of the user is known, Entrust IdentityGuard presents a set grid challenge. This ensures the challenge remains constant until it is successfully answered.

• Add an extra challenge for the user’s personal verification number (PVN) to make sure the grid card or token user is valid.

• Use a mutual authentication method to provide the user with a visual cue that the site being accessed is legitimate.

For example, display an authentication secret (for example, grid serial number or image) to the user during login. The absence of the number or image would suggest the site is fraudulent. See “Mutual authentication methods” on page 64.

• Use temporary PINs when users have lost or not received their grid, token, or passcode list.

• Determine which authentication method Entrust IdentityGuard should use, if the application does not specify.

Integrating with existing user management systemsIf you already have a user management system, you can incorporate Entrust IdentityGuard administration tasks into the application using the Administration API. The Administration API is the Java Platform or .NET API that you can use to integrate your applications with the Administration service in Entrust IdentityGuard. The Entrust IdentityGuard Administration interface is an example of an application using the Administration API.



106

For more information about implementing the Entrust IdentityGuard Administration API, see the Entrust IdentityGuard Programming Guide.

Using shared secretsEntrust IdentityGuard includes a feature called “shared secrets”. Shared secrets are name and value pairs associated with an Entrust IdentityGuard user and used by a client application. Shared secrets are not used by Entrust IdentityGuard, but you can manage them through Entrust IdentityGuard interfaces. They are stored in encrypted format in the repository.

There are several uses for shared secrets. For example, Entrust IdentityGuard Desktop for Microsoft Windows uses shared secret information to store the offline temporary PIN.

Note: Do not confuse shared secrets with authentication secrets or machine secrets (see “Mutual authentication methods” on page 64 and “Machine authentication” on page 67).



Using a Hardware Security Module (HSM)Entrust IdentityGuard has two master keys which are used to encrypt and protect the integrity of the information in the Entrust IdentityGuard repository. Because these keys are so important, you might want to store them on a Hardware Security Module (HSM). An HSM is a separate piece of hardware that is responsible for generating and storing keys, and performing all cryptographic operations involving those keys. By isolating keys and cryptographic operations to the HSM, the overall security of your system is improved.

You must decide whether you want to use an HSM prior to installing Entrust IdentityGuard Server. This is because the HSM settings must be specified when you install and initialize Entrust IdentityGuard Server—you cannot add an HSM after the product is already deployed.

Note: Although other keys are used in the Entrust IdentityGuard system—to secure SSL communications, for example—the HSM feature only applies to master keys.



108

Selecting a repositoryEntrust IdentityGuard stores data in a repository. A repository is either an LDAP-compliant directory or a JDBC-compliant database. An Entrust IdentityGuard system can contain one or more repositories, including a combination of both directories and databases.

Whenever an Entrust IdentityGuard operation requires a user's information, Entrust IdentityGuard searches the repository. Entrust IdentityGuard updates user information when required by administrative tasks, such as adding a new authenticator (such as a grid), or during authentication events that involve a challenge (such as grid coordinates).

When selecting a repository, consider where you currently store first-factor user credentials (user name and password). Typically you install Entrust IdentityGuard to augment first-factor user credentials for access to an application, such as a VPN or a Web-based system. Entrust IdentityGuard is designed to extend the information stored in existing repositories so you do not have to implement additional technology. However, directories and databases operate differently and can affect your decision about which type of repository to select for your system.

Entrust IdentityGuard provides a complete Administrative API that you can use (see “Entrust IdentityGuard Administration service” on page 32), so many differences between directories and databases can be hidden from users and administrators.

Directory repositoriesUser entries must exist in the directory before you can populate any Entrust IdentityGuard attributes. Entrust IdentityGuard cannot create any user entries in a directory. You must create users in the directory with your existing directory management tool, unless you are also deploying the Self-Service Module, which can be configured to create users in directories.

Entrust IdentityGuard cannot store unassigned grid patterns and token serial numbers in a directory, but stores them in either a local file system or a local database. In a configuration with a directory and a local file system, only a single Entrust IdentityGuard server can host the local file system, and all assignments of grids or tokens must be performed on that server. Availability of that server affects your organization's ability to assign grids or tokens. Using a local database to store unassigned grids and tokens supports a high availability configuration (see “High availability and disaster recovery” on page 115).

Entrust IdentityGuard offers additional features to enhance operation with your directory. You can configure Entrust IdentityGuard to:

• Using the user enrollment feature to create new users into Entrust IdentityGuard: User enrollment is supported only for LDAP repositories, so if you plan to deploy this Entrust IdentityGuard feature, you must use an LDAP repository for your installation. If your deployment contains both LDAP and



JDBC repositories, only users entered in the LDAP repositories are eligible for user enrollment into Entrust IdentityGuard. See “User enrollment from LDAP user repository” on page 163 for more information about this feature.

• Automatically suspending disabled and expired users: This feature, available only with LDAP-compliant repositories, allows Entrust IdentityGuard to read user status directly from the repository, and change their status in Entrust IdentityGuard.

• Also available: the ability to automatically update user contact information in Entrust IdentityGuard whenever it is updated in your LDAP directory.

Entrust IdentityGuard supports many widely-used directories. For more information, see the Entrust IdentityGuard Directory Configuration Guide.

Database repositoriesFor databases, no existing user entries need to exist before you can populate any Entrust IdentityGuard attributes. Entrust IdentityGuard can create new user entries in a database for you.

Entrust IdentityGuard stores unassigned grid patterns and token serial numbers in separate tables in a database. Using a database to store unassigned grids and tokens supports a high availability configuration (see “High availability and disaster recovery” on page 115).

You can also configure Entrust IdentityGuard audits to be written to a database. If your deployment includes generating reports of Entrust IdentityGuard audits, you must have at least one JDBC database deployed in your system. If you are planning to use a JDBC database for your Entrust IdentityGuard users, grid cards, and tokens, you can use the same database to store your system audits. If your user repository is an LDAP directory, you must configure a separate JDBC database for your Entrust IdentityGuard audit records. See “System monitoring” on page 90 for more information about this feature.

Entrust IdentityGuard supports many widely-used databases. For more information, see the Entrust IdentityGuard Database Configuration Guide.

Performance and maintainabilityThe performance of a repository can be a factor in environments with hundreds of thousands of users, or in environments where the existing user system is already heavily loaded. While your choice of repository does not affect Entrust IdentityGuard performance, you need to consider the impact of the additional load on your repository.

You may have your own preferences for a repository based on the level of skill within your organization to support and maintain it. You should choose a repository that



110

your organization is equipped to properly support and manage with the required response timing.

Entrust IdentityGuard supports a combination of both databases and directories, where each repository can support a different group of users. Your Entrust IdentityGuard system can use the mix of technologies that best meets the needs of your users and your organization.



Performance testing strategiesYou can perform tests to validate the performance characteristics of Entrust IdentityGuard in your environment. To perform these tests, use a commercial automated testing tool that allows for the creation of custom scripts that drive the testing process.

To perform Entrust IdentityGuard performance testing, create a script that simulates a user receiving a challenge and responding with the appropriate Entrust IdentityGuard response. The testing tool can then run this script as many times as needed to create a simulated load of the required size on the Entrust IdentityGuard Server.

To prepare the Entrust IdentityGuard Server for performance testing

1 Create test users.

2 Set up the test users with their appropriate authentication methods.

• If you are testing performance with grids, ensure the grids are generated, exported, and assigned to users. However, you do not need to print the grids. The script needs to have the values from each grid loaded into an array so that it can provide the correct response.

• If you are testing performance with tokens, ensure the tokens are loaded.

To run the Entrust IdentityGuard performance testing script

After the Entrust IdentityGuard Server is ready for performance testing, you can run the script. The script must perform the following steps:

1 Load the grid cells, one-time passwords, or tokens into an array.

2 Capture the start time for a transaction.

3 Send a request to the Entrust IdentityGuard Server requesting a challenge.

4 If you are using grids:

a Receive the challenge and parse it for the requested coordinates on the grid.

b Look up the correct values for the response in the grid cells.

c Optional. Pause for “think time” to simulate a person providing the response to the challenge.

5 Send a request to the Entrust IdentityGuard Server with the values of the grid, token, or one-time passwords.

6 Receive the response back from the server.

7 Capture the time that the transaction is completed and calculate the elapsed time since the request.

8 Report the elapsed time of the request to the screen, printer or file, as required.



112

After this script has been run a number of times and under different levels of load, you can tabulate the results into a report showing the performance of the overall Entrust IdentityGuard authentication system.

For information about repository size requirements, see either the Entrust IdentityGuard Directory Configuration Guide or the Entrust IdentityGuard Database Configuration Guide.



Backing up, restoring, and migrating from one platform to another

It is strongly recommended that you have a backup strategy in place before you install or upgrade Entrust IdentityGuard. Backing up your Entrust IdentityGuard system provides insurance in case something unexpected happens to the servers (such as a hardware failure). You must use a separate server or separate physical disk to host the backup files in case of a hard disk failure.

Your strategy should include the following:

• Selecting the type of backup to perform. In Entrust IdentityGuard, there are two backup options: full backups and partial backups.

– Full backups contain all information required to restore the configuration, logs, and file-based repository.

– Partial backups contain enough information to restore a replica system.• Backing up your repository on a regular basis, especially before installing or

upgrading Entrust IdentityGuard. Entrust IdentityGuard does not back up your data repository for you.

• Backing up and restoring all repositories together if the data is split over multiple repositories.

• Saving copies of the JDBC driver JAR files you used during installation, if you use a database repository.

A properly backed-up system can be successfully restored. See the Entrust IdentityGuard Installation Guide for restore instructions.

The backup and restore mechanism built into Entrust IdentityGuard lets you migrate from a UNIX platform to a Windows platform, or from a Windows platform to a UNIX platform.

To perform a platform migration

1 Backup your system configuration using the existing backup mechanism.

2 Copy the backup file to the new platform.

3 Install Entrust IdentityGuard on the new platform and, as part of the configuration steps, select to restore the configuration from a backup file.

4 Restore the configuration from the backup file.

This migration functionality was introduced in Entrust IdentityGuard 9.0. Older versions of Entrust IdentityGuard must be upgraded before migrating to another platform.



114

Switching users over to Entrust IdentityGuardDuring migration of an application from single-factor authentication to multifactor authentication, there will be a mix of users with and without Entrust IdentityGuard authentication methods. In this case, only users with Entrust IdentityGuard credentials should be prompted with the additional authentication challenges.

Migration from your RSA or other Radius-based authentication is easy; with Entrust IdentityGuard you can migrate your users automatically, as you are able to add them to the Entrust IdentityGuard repository. After users are added to Entrust IdentityGuard, their authentication requests are handled by Entrust IdentityGuard. Any users not yet migrated will continue to use your current authentication, and will automatically make the switch as you add them to the Entrust IdentityGuard system.

Creating users in Entrust IdentityGuardAs part of your migration to Entrust IdentityGuard, you add all your users to the Entrust IdentityGuard system.

If you are using an LDAP repository for your users, you can use the user enrollment feature to create Entrust IdentityGuard users directly from your repository. For details, see “User enrollment from LDAP user repository” on page 163.

Entrust IdentityGuard Self-Service Module, another product in the Entrust IdentityGuard family, allows you to customize user registration and user self-administration to make switching over to Entrust IdentityGuard even easier. Users can register to Entrust IdentityGuard, and the authentication types you define are automatically set up for them.



High availability and disaster recoveryEntrust IdentityGuard offers a failover scheme to ensure there are backup systems in place in the event that a primary system fails. This scheme addresses high availability and disaster recovery issues as described here:

• “Entrust IdentityGuard Server hot-standby and load-balancing” on page 115

• “Repository failover” on page 117

• “Radius server failover” on page 120

For procedures for configuring these failover scenarios, see the Entrust IdentityGuard Server Administration Guide.

All data sources (databases, directories, Radius servers, external authentication sources) that Entrust IdentityGuard uses are listed in specific properties in the Entrust IdentityGuard properties file. To set up a common failover mechanism, you use the Properties editor to list two or more URLs for each applicable property. The URLs point to the data sources or servers.

When Entrust IdentityGuard needs to access a server or data source, it tries the first URL in the list (known as the primary). If the connection succeeds, Entrust IdentityGuard uses it until it fails. When the primary fails or is unavailable, Entrust IdentityGuard tries the second URL in the list. If it fails or is unavailable, Entrust IdentityGuard tries the next URL, and so on. In failure cases, Entrust IdentityGuard always restarts at the primary source and traverses the URL list until it makes a valid connection. During the traversal, the connection that caused the original failure is skipped.

Entrust IdentityGuard Server hot-standby and load-balancingYou can set up multiple Entrust IdentityGuard servers to operate in load-balanced mode, or you can set up a separate Entrust IdentityGuard server as a hot-standby in case the primary server becomes unavailable.

Figure 22 on page 116 shows the hot-standby scenario. The solid line shows the primary connection, while the dotted line shows the hot-standby connection.

The Client APIs available with Entrust IdentityGuard Server include the ability to fail over to a hot standby server.

Figure 23 on page 116 shows the load-balanced scenario. A load-balancer is placed in front of the Entrust IdentityGuard Servers to distribute the load.



116

Figure 22: Hot-standby scenario

Figure 23: Load-balanced scenario



Repository failoverYou can configure repository failover to ensure there are backups if the primary repository fails. To configure failover, use the Properties Editor to specify multiple repository URLs—either LDAP-compliant directories or databases—in the Entrust IdentityGuard properties file.

To configure failover for an LDAP-compliant directory or a database, see the Entrust IdentityGuard Server Administration Guide.

There are two repository failover scenarios:

• local

• geographically dispersed

Local repository failoverIn this scenario, the users are usually in one office or city. You can use two databases or two LDAP-compliant directories in this scenario, but using one of each is not recommended.

There is a primary repository and a secondary repository. The two repositories are kept synchronized. If the primary repository fails, traffic is redirected to the secondary repository.

Figure 24: An example of a local repository failover scenario



118

Geographically-dispersed repository failoverThis scenario demonstrates how you can deploy failover for Entrust IdentityGuard users in two different cities (for example, Los Angeles and New York). The Entrust IdentityGuard Server in each city is connected to its own repository. If the repository in Los Angeles fails, the Entrust IdentityGuard Server in Los Angeles can connect to the New York repository.

Standard multi-site failover configuration

In the standard configuration, each Entrust IdentityGuard server works from its own repository, but the two repositories must be perfect replicas of each other.

Note that when you use geographically-dispersed Entrust IdentityGuard servers, both servers can perform authentication tasks, but the primary Entrust IdentityGuard server must provide the Administration services.

In Figure 25, the solid lines show the normal operating connections, and the dotted lines show possible failover connections.

Figure 25: An example of a standard geographically-dispersed failover scenario



Advanced multi-site failover configuration

You can also set up separate storage for user, unassigned token, and preproduced grid data, both in the same repository or in separate repositories.

One site must maintain the master repository, containing and maintaining all of the data for the full Entrust IdentityGuard systems. The secondary repository maintains its own local data, which must be uploaded to the master repository at regular intervals.

Using the example in Figure 26, users in Los Angeles would still have access to their applications and be able to authenticate using the New York server.

In this more advanced configuration, the master repository contains all of the data and policy information, while the secondary repository contains only local data. This allows high availability without worrying about the same data being changed in both repositories. Organizational procedures ensure that the local data in each site is read-only from the other site, while maintaining all the data from the entire Entrust IdentityGuard system in the master repository.

Figure 26: An example of an advanced multi-site failover scenario



120

Radius server failoverConfigure Radius server failover on the Entrust IdentityGuard Radius proxy to ensure that there are backup Radius servers if the primary system fails. If a timeout occurs while waiting for a response from the Radius server—and Radius server failover is configured—Entrust IdentityGuard Radius proxy uses the next URL address in a list (for the next request that it receives) and the current request times out. When the Entrust IdentityGuard Radius proxy reaches the end of the list of URL addresses, it starts at the beginning of the list again.

To create the list of Radius server IP addresses, see the Entrust IdentityGuard Server Administration Guide.

Figure 27: An example of a Radius server failover scenario



6

Deploying grid authentication

This chapter provides deployment information for grid authentication. Most of the information applies to the deployment of grids, but you should also read this chapter if you are deploying passcode list authentication.


• “Grid requirements” on page 122

• “Challenge requirements” on page 125

• “Grid card production models” on page 127

• “Grid security” on page 135

• “Physical grid card production options” on page 136

• “Secure file transmission” on page 141

• “Automating processes” on page 142

121

122

Grid requirementsThis section focuses on the items you need to consider before determining what type of grid best suits your security needs and your users.


• “Grid size and format” on page 122

• “Grid lifetime and replacement” on page 123

Grid size and formatYou can configure the size (the number of cells) and format (the contents of cells) of a grid according to your organization’s policies. Although both are configured, the grid size has more impact on security than the format of cell contents. (Do not confuse grid size with challenge size—the number of cells presented to the user at authentication.)

Grid size impactThe more cells in a grid, the better the resistance to an attacker who has gained some knowledge of a user’s grid through impersonation.

For example, if an attacker successfully captures one successful login with three coordinates, they are less likely to receive a subsequent challenge with those coordinates using a 5 x 10 grid card as compared to a 3 x 8 grid card. To minimize the probability that an attacker can use captured cells in subsequent challenges, the grid size should be maximized within the constraints of usability.

Regarding usability, Entrust commissioned independent studies that show equal usability for a 5 x 10 grid card and a 7 x 12 grid card. This means organizations can deploy larger grids to users for scenarios that require higher security. For more details on this and other recommendations, see “Grid card usability study” on page 223.

Note: It may be appropriate within a user population to deploy various grid sizes depending on the frequency of use and the transaction risk. Entrust IdentityGuard supports this approach by allowing you to set up users in groups. See “Group requirements” on page 98.

Grid format impactCell format has a direct impact on cell value unpredictability (also called “cell entropy”), or how difficult it is for someone to guess cell values. Cell format choices include using alphanumeric characters instead of numeric only, and using more than one character per cell.



Cell entropy is related to the number of potential characters for each cell in the grid. If a grid uses only single numeric digits, there are just 10 potential entries per cell, however if the grid uses single alphanumeric characters instead, each cell has 36 possibilities. The greater the number of possibilities, the more difficult it is for an attacker to overcome the randomness of the challenges.

Table 22 lists the policy considerations related to grid size and format.

Table 22: Policy considerations associated with grid size and format

Policy consideration Recommendations

Rows and columns in grid Maximize the number of rows and columns within physical form and usability constraints.

Characters in grid Use single alphanumeric characters.

Characters per cell Use one character per cell for maximum usability.

Characters that can replace other characters

Consider having replacement characters for:

• characters that are easily confused with others (for example, the letters U and V, or the letter O and the number 0)

• uppercase and lowercase characters (such as A and a)

Grid lifetime and replacementGrids provide a strong defense against short-lived phishing attacks; however, a long-term pharming attack could obtain sufficient information over time to gradually reduce a grid’s effectiveness. Therefore, replace Entrust IdentityGuard grids periodically to provide continuous protection of your users’ identities. There is no single replacement period that will work for all applications.

You can configure grid lifetime and replacement based on:

• time (for example, one year)

• usage (for example, when over 50% of the grid is used at least once)

This enables you to fit the renewal cycles to specific risk scenarios or user groups (see “Group requirements” on page 98). By configuring the grid lifetime and replacement policies, you can configure Entrust IdentityGuard to address identity fraud risk on a per group basis, where groups get new grid cards more or less frequently depending on the risk.

Table 23 on page 124 lists the policy considerations related to grid lifetime and replacement.

123Deploying grid authenticationReport any errors or omissions


124

Table 23: Policy considerations associated with grid lifetime and replacement

Policy consideration Recommendations

Lifetime based on time or usage? • If your users authenticate infrequently, base the lifetime of the grid card on time.

• In higher-risk or transaction-intensive situations, renew a grid based on usage.

Lifetime of card if based on time • Given the short window of opportunity for specific attacks, a life span of one year or more is recommended.

Replacement and warning thresholds

• Scan the logs or run reports regularly to search for card grids that are nearing expiry or usage thresholds and initiate the replacement process.

• Ensure your users have sufficient time to obtain a new grid card when their current one is about to expire.

• If a grid expires before a replacement grid card is received, you can issue temporary PINs. You can use knowledge-based authentication to validate users’ identities when they call to report an expired grid card. For more information, see “Entrust IdentityGuard users” on page 39.



Challenge requirementsThis section focuses on the factors to consider before determining what type of grid challenge best suits your security needs and your users.


• “Challenge size” on page 125

• “Challenge algorithm” on page 126

Challenge sizeYou can configure the size of the Entrust IdentityGuard challenge (the number of cells in a grid challenge), and this has an impact on the security of the solution.

• The greater the number of cells used in a challenge, the more data is given away with each observation by an attacker.

For example, should users be tricked into entering a single authentication to an attacker’s application, they would be giving away twice as much grid data with a challenge size of six coordinates as with three coordinates. The more data that is given away, the more quickly an attacker will gather enough data to answer a challenge from the legitimate application.

• The challenge needs to be of a minimum size to reduce the probability that an attacker can guess some or all of the challenge coordinate responses.

For example, assume an attacker successfully captures some grid card data and then attempts to authenticate. The attacker receives a challenge in which one of the challenge coordinates is already known to the attacker. With a challenge size of two, the attacker has a much better chance of obtaining the remainder of the challenge by guessing than if the challenge size was four, especially since the Entrust IdentityGuard lock-out feature limits the authentication attempts.

• Find a balance between the minimum and maximum constraints when you set the optimal challenge size for a given grid size.

For most applications, the optimal challenge size is three. This number provides the best overall resistance to an attacker guessing remaining challenge coordinates across a range of observed authentications.

Varying the grid challenge sizeThrough policy settings, you can present a different number of grid challenges based on the type of access or transaction the user requires and the risk associated with the site. For example, access to an internal company intranet portal could require three grid coordinates while access to an external Web-based investment site could require four coordinates.



126

Challenge algorithmEntrust IdentityGuard includes two types of challenge generation algorithms for grid authentication:

• Random picks cells randomly when creating a challenge (this is the default). The process for creating one challenge does not depend on previous challenges.

• Least-used uses a configured number of least-used cells in every challenge. You can set the policy to use one least-used cell per challenge up to the entire challenge.

By generating challenges using the least-used cells from an user’s grid, it becomes more difficult for an attacker who has previously viewed some successful authentications to correctly respond to the challenge. However, it limits the useful life of the grid, depending on the least-used threshold (see “Grid lifetime and replacement” on page 123).



Grid card production modelsAt a high level, Entrust IdentityGuard grid and passcode list production requires the following activities:

• In an LDAP directory environment, the user must already exist in the directory.

• Create the user in Entrust IdentityGuard.

• Generate grid (or passcode list).

• Assign grid (or passcode list) to user.

• Produce a physical card containing the grid (or passcode list).

Entrust IdentityGuard provides two models for grid production: a produce-and-assign model and a preproduction model.

• The produce-and-assign model involves generating a grid for each user as needed. The produce-and-assign model is suitable for situations where the user is already known to the organization and already exists in the repository.

• The preproduction model involves generating grid cards in bulk and then assigning them to users later. The preproduction model is suitable when the user is not known to the organization or when the grids are assigned to users after generation.

Alternatively, you may choose to use Entrust IdentityGuard Self-Service to email eGrids to users. Distribution of eGrids generally follows the produce-and-assign model. Self-Service Module supports the assignment of eGrids and physical grid cards in either of the two distribution models.

As illustrated in Figure 28, the order in which these activities occur varies between the produce-and-assign model and the preproduction model.

Figure 28: Grid production models

1. User exists in primary application

2. User created in Entrust IdentityGuard

3. Grid generated for user

4. Card produced

1. Grid generated

2. Card produced

3. User exists in primary application

4. User created in Entrust IdentityGuard

5. Grid assigned to user

Produce -and-assign model

Preproduction model



128

These two models are not mutually exclusive. For example, an organization may use the preproduction model for new users and use the produce-and-assign model for existing users. The organization could also use the preproduction model for Entrust IdentityGuard grid card replacement.


• “Produce-and-assign model” on page 128

• “Preproduction model” on page 132

Produce-and-assign modelIn the produce-and-assign model, the user (who will receive an Entrust IdentityGuard grid card or eGrid) must be known in advance of grid creation. The user is created within the first-factor authentication application. Then use the Entrust IdentityGuard Create User function to populate the user entry in the repository with the Entrust IdentityGuard attributes. During the user creation process, a grid is generated for the user.

In this model, grid card production and distribution must take into account that a grid has already been created and assigned to a user within Entrust IdentityGuard. Therefore, the physical card containing the grid must be distributed to the correct recipient. If you are distributing eGrids, production is not required.

This approach is manageable for small-scale usage (a few grid cards a day), where the entire enrollment process is handled as an over-the-counter service, completed in a few minutes. One advantage to this process is that it easily supports Entrust IdentityGuard grid card personalization, such as printing a photograph on the grid card.

Entrust IdentityGuard Self-Service Module eGridsThe produce-and-assign model for grid distribution is particularly easy to manage when using Entrust IdentityGuard Self-Service Module to send eGrids to users through email. When emailing eGrids, the rest of the production process is not necessary—the eGrids are automatically produced and delivered with no administrator action required.

Producing and assigning physical grid cardsThe following subsections provide more detail on how to produce and assign grids when enrolling existing and new users:

• “To produce and assign grids for existing users” on page 129

• “To produce-and-assign grids for new users” on page 130



To produce and assign grids for existing users

Follow this procedure if you are using the produce-and-assign model for existing users.

Figure 29: Grid production for produce-and-assign model (existing users)

7. Extract user information into second file

2. Extract list of users

3. Generate grids

4. Export production file

8. Merge two files to create production file

9. Review and deal with errors

5. Securely transmit file to card producer

Optional steps required if user delivery information is not in Entrust IdentityGuard Repository .

1. Entrust IdentityGuard

Repository 6. Other repository

1 Ensure the users already exist in the Entrust IdentityGuard repository.

2 Extract a list of the users from the repository who are to receive grid cards.

3 Import the list of users into Entrust IdentityGuard and generate the grids for those users. For detailed instructions, see the Entrust IdentityGuard Server Administration Guide.

4 Export the selected users’ grids, user IDs, and delivery information into an Entrust IdentityGuard production file.

5 Securely transmit the Entrust IdentityGuard production file to the grid card production facility where grids are printed on cards or another appropriate medium. See “Secure file transmission” on page 141.

Each user ID and grid combination must include the associated user ID and delivery information. If this information is located in the Entrust IdentityGuard repository, it is exported along with the user ID and grid. If the information is located elsewhere, it must be extracted and matched or merged with the user IDs and grids. The optional process steps are listed below.

6 (Optional) Based on the list of user IDs exported, access other corporate repositories to obtain the name and mailing information of the selected users.

7 (Optional) Export the user information into a second file.



130

8 (Optional) Merge the two files together to create the Entrust IdentityGuard production file containing the user information and associated grid information.

9 Report the exceptions in which user information cannot be found for a user, and resolve them in a separate process.

10 Complete the enrollment process with “Maintenance” on page 173.

To produce-and-assign grids for new users

Implement the following steps if you are using the produce-and-assign model for new users.

Figure 30: Grid production for produce-and-assign model (new users)

2a. Administrator requests card

3. Generate grids


Repository

2b. User logs in and requests card

2c. Cards requested in bulk



1 Ensure the user exists in the primary application’s repository. This repository also serves as the Entrust IdentityGuard repository.

2 Request the grid cards for the new users, using one of the following three methods:

a Have the administrator request the grid card.

In an over-the-counter approach, the request for an Entrust IdentityGuard grid card is submitted by the administrator. This approach is manageable for small-scale usage (a few grid cards a day), where the entire enrollment process is handled as an over-the-counter service, and completed in a few minutes. One advantage to this process is that it easily supports Entrust IdentityGuard grid card personalization, such as printing a photograph on it

b Have the user log in to Entrust IdentityGuard Self-Service Module and request the grid card.



This login is performed using a current user name and password. For example:

– An organization implements the application on an internal Web site accessible to anyone on the network with a valid user name and password.

– The application authenticates the user.– The user creates a request, using the user name for which the Entrust

IdentityGuard grid card is being requested. This user name must either exist in the repository or the application must create a new user account at this time. For example, the user name might be obtained or derived from the network login user ID to simplify the request for the user.

c Create a central service that uses a bulk operation to generate Entrust IdentityGuard grid cards for many users at once.

An administrator extracts information from the repository to select users for whom Entrust IdentityGuard grid cards will be issued. For each user, the extracted information must contain the user name and delivery information. The delivery information depends on the delivery method. For more information see “Maintenance” on page 173.

3 Entrust IdentityGuard generates and assigns a grid to each user name.

4 An administrator exports the Entrust IdentityGuard production file. It contains:

• the user name and grid information

• personalization and delivery information extracted from the repository

Using the user name as a key, the extracted information is merged with the grid data and any information required to print the grid on a physical card. The output of this process is an Entrust IdentityGuard production file.

Variations will occur in the process. Depending on the service approach, the Entrust IdentityGuard production file may consist of a single grid or many grids. An over-the-counter service will produce grid cards one at a time, while the other approaches produce grid cards in quantity. The processes to produce the Entrust IdentityGuard production file may merge the request information for new grid cards, renewal grid cards and replacement grid cards into a single file.

5 Produce the grid cards.

• Send a production file to an application for grid card production and subsequent delivery. For details, see “Physical grid card production options” on page 136.

• If you are using the over-the-counter approach, keep a stock of blank cards at the Service Desk for printing at the time of enrollment. The enrollment process should take only a few minutes and the Entrust IdentityGuard grid card would be handed to the user on the spot.

6 Complete the enrollment process with “Maintenance” on page 173.



132

Preproduction modelIn the preproduction model, users are not necessarily known in advance. A set of grids is generated, but not assigned to specific users. (You would not normally preproduce eGrids.) A grid is assigned to a user at some point during the user registration and activation process. How and when the assignment occurs depends on the user administration processes in place.

How the grid card production models are used plays a significant role in user life cycle management. See “User life cycle management” on page 159.

Figure 31 shows the steps involved in the generation of the Entrust IdentityGuard production file for the preproduction model. In this model, anonymous grids are created. Grid assignment happens later in the registration process.

Anonymous grids can be sent to users in the mail. When the user receives a grid card in the mail, they assign the grid card to themselves at a self-enrollment Web site. At such a Web site, you can configure Entrust IdentityGuard to challenge the user to prove that they have the grid card, rather than just ask for the serial number. For example, after the user enters their serial number, they are presented with a grid challenge. If the grid challenge fails, the grid card stays in the unassigned state. This is to ensure that the user does not assign the wrong grid card to themselves by entering the wrong serial number.

Also, users can receive their anonymous grids in person. For example, a bank teller can pull a grid card out of a box to give to a customer in a bank branch. In this model, grid cards should have a tamper-evident sticker that covers the grid, but not the serial number.

Figure 31: Grid production for preproduction model

4. Card creation and delivery

6. Create user, select card, assign grid



1. Generategrids and store in

repository


Repository



To preproduce grids

1 Create a set of Entrust IdentityGuard grids and assign the grids to a particular user group. For information about where preproduced grids are stored, see “Repository” on page 34.

The only information generated after this step is the serial number and contents of the grid.

2 Export the unassigned grids by writing the serial numbers and grid configurations to an Entrust IdentityGuard production file.

For information on exporting grids, see the Entrust IdentityGuard Server Administration Guide.

3 Securely transmit the Entrust IdentityGuard production file to the grid card production facility where grids are printed on cards or another appropriate medium. See “Secure file transmission” on page 141.

4 Produce the grid cards using one of the following methods:

• Send the Entrust IdentityGuard export file to an application for grid card production and shipment back to the organization, which stores the unassigned grid cards until needed.

• Append the file with additional information relevant to the grid card production facility. For example, if grid card production is outsourced then the outsourcer will need billing information from the requesting organization.

The remaining steps are completed once the grid cards are created and delivered.

5 If you use an LDAP-compliant directory as the Entrust IdentityGuard repository, ensure the user entry exists in the directory.

6 Create the user in Entrust IdentityGuard, select the grid card and assign the grid to the new user, using one of the following methods:

• Have the administrator select the grid card and assign it to the user.

In an over-the-counter approach, the administrator assigns the grid cards when the user is present and hands the grid card to the user at that time. This approach is manageable for small-scale usage (a few grid cards a day), where the entire enrollment process is completed in a few minutes. One advantage to this process is that it easily supports Entrust IdentityGuard grid card personalization, such as printing a photograph on the grid card.

• Deliver the grid card to the user, and have the user log in to a Web application (or something similar) to register the grid. When registering the grid, the user provides the grid card’s serial number, which is used to assign the grid to the user.

Login to the Web application is performed using a current user name and password. For example



134

– An organization implements the application on an internal Web site accessible to anyone on the network with a valid user name and password.

– The application authenticates the user.– The user creates a request to set up their Entrust IdentityGuard account,

using the serial number of the Entrust IdentityGuard grid card. This serial number must be made available to the user either on the grid card itself, or in documentation sent with the grid card.

Entrust IdentityGuard generates and assigns a grid to each user name regardless of where the request originated.

Forcing grid card activationWhen new Entrust IdentityGuard users are first assigned grid cards, they can continue to log into your system using just their user name and password until they activate through Entrust IdentityGuard. This gives users a grace period between the time the grid cards are mailed and when they are received. However, users can ignore the grid card enrollment process and continue to log in without using the grid cards even after they arrive. This represents a way to avoid second-factor authentication.

Entrust IdentityGuard lets you specify through a policy setting that new users must activate their new grid cards within a certain period of time. After the date implied by the grace period, their first-factor authentication access is blocked until they activate their grid card. Once they have activated the grid card, they can never use just first-factor authentication again.



Grid securityEntrust IdentityGuard can be deployed in several ways, although many deployments will use a standalone physical card for a unique grid.

• Use the Entrust IdentityGuard feature allowing you to display the user’s last successful login time and date. If this information does not match the user’s personal experience, this alerts the user that some form of attack may have occurred.

• Define a user policy and educate users on appropriate grid handling to prevent users from unwittingly exposing their grid data to an attacker, both physically and electronically.

Physical grid card securityThe existence of a physical card that must be carried opens up the risk that the card may be lost or stolen. In addition to other measures, consider the following:

• Do not put specific information or branding on the grid card that will identify your site as a potential attack point if a grid card is lost or stolen.

• Include anti-copying measures such as using hard-to-duplicate color combinations or reflective card materials (though make sure the colors do not reduce usability).

eGrid securityUsing eGrids emailed as a file requires a different set of security procedures, since the eGrid can be printed any number of times, and left out in the open in any number of circumstances.

In addition, eGrids in email messages are vulnerable to interception in the same way any other email may be.

You should consider using eGrids in PDF format, since Self-Service Module can take advantage of PDF features to password-protect eGrids and control their use.

Users should be instructed in the procedures and precautions necessary to keep their eGrids secure from unauthorized people, whether in their email, on their computer, or in printed form.



136

Physical grid card production optionsYou can choose from two basic options for grid card production:

• in-house (“In-house grid card production” on page 136)

• outsourced (“Outsourced grid card production” on page 137)

If there is no existing grid card production process, or the existing process is unsuitable, Entrust can help with its own grid card production service capability. See “Entrust IdentityGuard grid card production” on page 139 for more information.

Note: For users who are visually impaired, you can produce the grid cards with Braille characters. If you do produce grid cards with Braille characters, ensure that your application does not conceal challenges (such as presenting challenges as images), but presents the challenges in machine-readable text.Entrust IdentityGuard clients have successfully met their 508 standards obligations using grid cards with Braille characters.

Also see “Grid card production cost factors” on page 139 and “Maintenance” on page 173.

In-house grid card productionUse the in-house approach if you are leveraging existing grid card production capability (for things such as security badges) to produce and distribute Entrust IdentityGuard grid cards.

Typical characteristicsThe following are general characteristics of deployments involving in-house grid card production (note that these characteristics do not exclude an outsource approach for deployment):

• used for Enterprise deployments where grid card production already exists

• grid cards are distributed at either over-the-counter service locations or through existing corporate mailing facilities

SetupThe following areas need to be addressed prior to starting any in-house Entrust IdentityGuard grid card production:

• Review internal departmental agreements and process.

• Check the inventory of existing card stock (for example, letter stock, card artwork, logo, branding).



• Create a welcome letter and activation instructions for users.

• Ensure secure intra-departmental transmission capability

– for Entrust IdentityGuard grid card generation information– for Entrust IdentityGuard grid card distribution (over-the-counter or

internal corporate mail)

ProcessThe following process steps are required with in-house Entrust IdentityGuard grid card production. (These steps may vary based on corporate procedures and policy.)

To produce grid cards in-house

1 Securely send the Entrust IdentityGuard production file to the grid card production location in a secure manner. See “Secure file transmission” on page 141.

2 Analyze the Entrust IdentityGuard production file and select the appropriate card or paper stock for printing.

3 Produce the Entrust IdentityGuard grid cards.

4 Notify the user about grid card pick-up and activation, or mail the grid card based on user address information included in the Entrust IdentityGuard production file; for example, you can use the company’s internal mailing information.

5 Activate the grid in one of two ways:

• Have an administrator authenticate the user face-to-face at the over-the-counter service desk.

• Have the user follow the activation instructions contained in the Entrust IdentityGuard grid card mailing.

Outsourced grid card productionFor quantities greater than 1000, Entrust can assist in sourcing an appropriate grid card production partner. For information about outsourced grid card production options, contact Entrust (“Obtaining technical assistance” on page 18).

For quantities up to 1000, you can use the Entrust IdentityGuard Card Production Service. For more information on this service, see “Entrust IdentityGuard grid card production” on page 139.

If you already use an outsourced grid card production facility, negotiate the contracts and service level agreements, and update the facility with the new requirements and procedures for transmitting grid card and user data.



138

Typical characteristicsThe following are general characteristics of deployments involving outsourced grid card production:

• The organization does not have an internal grid card production capability or elects not to use the internal capability.

• The organization is a large, geographically dispersed company.

SetupThe following areas need to be addressed prior to starting any outsourced Entrust IdentityGuard grid card production:

• Select a grid card production facility for Entrust IdentityGuard grid card production and distribution (Entrust can recommend a grid card production partner).

• Create grid card production partner agreements.

• Write a welcome letter and activation instructions for users.

• Secure inter-organization transmission capability

– for Entrust IdentityGuard grid card generation information– for Entrust IdentityGuard grid card distribution

• Send grid cards to users or deliver grid cards to the service desk for internal distribution.

ProcessThe following steps are involved in outsourcing Entrust IdentityGuard grid card production.

To outsource grid card production

1 Securely send the Entrust IdentityGuard production file to the grid card production facility in either an encrypted file format or a secure FTP arrangement.

2 Analyze the production file and select the appropriate card or paper stock for printing.

3 Analyze the production file for personalization information to be printed on the individual Entrust IdentityGuard grid cards.

4 Analyze the production file for grid card shipping instructions.

5 Produce the grid cards and insert them into addressed envelopes for distribution.

6 Distribute the grid cards using the shipping instructions provided in the production file. You can ship the grid cards to the user directly, or distribute the grid cards from a central location (such as a service desk).



7 The user follows the activation instructions contained in the grid card mailing.

Entrust IdentityGuard grid card productionFor quantities up to 1000, the Entrust IdentityGuard Card Production Service (available from Entrust TrustedCare Online) provides a convenient and secure way to order Entrust IdentityGuard grid cards over the Web. Administrators can order grid cards online against a previously issued purchase order. Administrators also have the flexibility to modify the grid card template to meet their requirements.

Typical characteristicsThe following are general characteristics of deployments involving Entrust IdentityGuard grid card production:

• The organization using Entrust IdentityGuard grid cards does not have an internal card production capability or elects not to use the internal capability.

• The organization would like to set up a quick pilot deployment.

• The organization does not need many grid cards (1000 grid cards or less)

SetupBefore starting any Entrust IdentityGuard grid card production, you must select one of three card options:

• a generic card with a preproduced grid

• a generic card with a customer-assigned grid

• a customer card with a customer-assigned grid

For more information on this topic, see the Entrust IdentityGuard Card Production Service User Guide.

Grid card production cost factorsThere are many factors that influence the cost of Entrust IdentityGuard grid card production. Table 24 describes a few of these factors.

Table 24: Factors that influence the cost of grid card production

Card/paper quality • The cost increases as the card thickness increases.

• Removable scratch covers increase cost.

Grid Card volume • Higher volumes cost less per grid card.

Branding detail (logos, colors)

• More colors and complex graphics increase costs.



140

Personalization detail • Bulk production of unassigned grid cards is cheaper.

• Personalization requires creating and matching the insert letter and envelope with the correct grid card for each user.

• Personalization requires the protection of personal information, which may increase the cost because of secure file transmission.

Distribution requirements

• Where and how the grid cards are shipped influences costs.

• Bulk mailing versus individual distribution, standard post versus courier, and remote geographical locations all affect costs.

Table 24: Factors that influence the cost of grid card production (continued)



Secure file transmissionEnsure that the Entrust IdentityGuard production file and any personal information (for example, name and address) of the user is transferred securely. The following sections describe several transmission technologies.

Secure Sockets LayerThe Entrust IdentityGuard Card Production Service provides an SSL (Secure Sockets Layer)-protected Web site with electronic forms that accepts the Entrust IdentityGuard production file as an attachment. This protects the data by encrypting it in transit. This technique is simple to employ and uses well-understood technology.

Secure emailYou can transmit the Entrust IdentityGuard production file as an attachment in a secure email using S/MIME or PGP. This ensures that only the intended recipient can open the file for subsequent processing. You can also digitally sign the email to validate your identity. This technique is simple to employ and uses well-understood technology, if you have a secure email system.

Secure FTPYou can transmit the Entrust IdentityGuard production file using an encrypted FTP session. The data is encrypted in transit and, depending on the implementation, may also be digitally signed for integrity. It requires the receiving organization to set up a secure FTP server and to provide access to the sending organization. While the setup may take longer than SSL or secure email, secure FTP allows for automated transmission, which is important in very large deployments.

End-to-end encryptionAn alternative to secure FTP is to encrypt and digitally sign the Entrust IdentityGuard production file prior to transmission. You can then transmit the file by any available means (for example, HTTP, email, or FTP), because only the intended recipient can open the file for subsequent processing. The recipient can be a person who will submit the file for processing, or an application that decrypts the file immediately before processing it. This technique provides the broadest security for the Entrust IdentityGuard production file, but this technique requires careful planning to implement. Consideration needs to be given to the management of the encryption keys, which can be assisted with the use of a public key infrastructure (PKI).



142

Automating processesTo enhance the existing functionality of Entrust IdentityGuard and facilitate deployment, the following list and highlights areas that are candidates for automation. Actual implementation details will differ depending upon your specific requirements and environment. These methods are in addition to the functions you can provide to your users by deploying Self-Service Module.

• Entrust IdentityGuard provides a mechanism for exporting grid cards in XML or CSV format for existing users. To automate this export, an application exports the grid information to an XML file. The application could run unattended as a batch job, and also encrypt the XML information for secure transfer. Additional functionality to manipulate the format of the file or add user information may also be required, depending on the requirements of the grid card producer.

• Depending on the grid card production and distribution model chosen, there may be a requirement to extract user information, such as name and address, from other corporate information sources. In this case, you could write a generic application to extract user information and make it available in an encrypted XML or CSV file. The application would use the Entrust IdentityGuard user name as a key to extract the user’s full name and mailing information.

• Bulk user creation abilities and an automated application allows an administrator to extract information from the Entrust IdentityGuard repository and put it into the correct format for input into bulk operations.

• Meet reporting and auditing requirements by developing an application that generates reports detailing users with grid cards in different states. You can run this reporting application unattended as a batch job at any time. For information on the grid card states, see the Entrust IdentityGuard Server Administration Guide.

• Entrust IdentityGuard provides interfaces for administrators to perform user management activities, and APIs that you can use to build a -service application for users. “User life cycle management” on page 159 describes the process models for user self-service; write a Web application to support this model using the Entrust IdentityGuard Administration API. For more information, see the Entrust IdentityGuard Programming Guide that applies to your programming language (Java Platform or .NET).



7

Deploying token authentication

This chapter provides deployment information for token and soft token authentication.


• “Using tokens for authentication” on page 144

• “Using soft tokens for transaction verification” on page 145

• “Token deployment” on page 146

• “Token security” on page 148

143

144

Using tokens for authenticationUsers can authenticate to Entrust IdentityGuard using tokens. Once Entrust IdentityGuard and users are set up to accept tokens, users must enter a dynamic password (the random number generated by a token device) in response to an Entrust IdentityGuard token challenge. There are two types of token:

• hardware tokens

A hardware token is a token that comes with a physical casing

• soft tokens

A soft token is a software-only version of a hardware token that is installed onto a device such as a mobile phone or laptop. Entrust IdentityGuard supports two soft token applications: Entrust IdentityGuard Mobile (for mobile devices) and Entrust IdentityGuard Soft Token (for PCs).

Your application is not limited to one type of token or one token vendor. You can configure Entrust IdentityGuard to use a wide range of tokens, both hardware and software. The default installation of Entrust IdentityGuard supports several types of Entrust hardware tokens as well as Entrust IdentityGuard Soft Token and Entrust IdentityGuard Mobile soft tokens. Each user can have multiple tokens at the same time, and they do not have to be from the same vendor.

Token lifetime and replacementIf the current token has low batteries, you can associate a pending token with the user entry to replace the existing token. Once the user authenticates with the new token, the state of the new token changes from pending to current. The old token is canceled by Entrust IdentityGuard.

Allowing users to have multiple tokensIf the need arises, you can configure Entrust IdentityGuard to allow a single user account to have multiple current tokens. For example, you might want to let a user have a soft token on their BlackBerry smart phone for use while on the road, and a hardware token for office use. As another example, you might have a husband and wife sharing the same user account, in which case you might want to allow each to have their own token.

For more information on token states and the multi-token feature, see the Entrust IdentityGuard Server Administration Guide.

Entering token responseThe user’s token device generates the dynamic password (a number) that a user enters at the challenge. Entrust IdentityGuard checks if the dynamic password is valid and, if it is, authenticates the user.



In addition to a token’s dynamic password, you can also have the user enter a personal verification number (PVN) when authenticating. See “Using personal verification numbers” on page 82.

A PVN consists of a string of numeric characters that users must enter with their dynamic password when challenged by Entrust IdentityGuard. For example, if the user’s PVN value is 1234, and the dynamic password value is 789789, the user must enter 1234789789 as the authentication challenge response.

Using soft tokens for transaction verificationTransaction verification is an optional feature available for use with Entrust IdentityGuard Mobile soft tokens. When enabled, users receive, on their mobile devices, details of pending transactions they have started at your Web site—a money transfer, for example. Users are then asked to confirm the transaction. For details, see “Transaction verification” on page 79.

145Deploying token authenticationReport any errors or omissions


146

Token deploymentHardware tokens and soft tokens are deployed differently.

• “Deploying hardware tokens” on page 146

• “Deploying soft tokens” on page 147

Deploying hardware tokensHardware token deployment is similar to preproduced grid card deployment. The main difference is in the method used to add tokens to the repository. A box of tokens comes with a data file. You add tokens to an Entrust IdentityGuard repository by importing the token manufacturer's data file. Once the token data is loaded, you supply token devices and assign token serial numbers to your users.

When the data file is loaded into the repository, the tokens are loaded as unassigned tokens. Tokens must be assigned before they can be used for authentication.

Assigning tokensA master user or administrator assigns tokens to users. Tokens have the same states as grid cards (pending, hold_pending, current, hold and canceled). Only tokens that are in the pending and current states are used for authentication. Token states have the same transition behavior as for grid cards. For more information on token states, see the Entrust IdentityGuard Server Administration Guide.

User tokens do not have an expiry date or a superseded date. Any token can be unassigned and added back to the unassigned tokens list.

Forcing token activationWhen new Entrust IdentityGuard users are first assigned tokens, they can continue to log into your system through their VPN or other connection using just their user name and password until they activate through Entrust IdentityGuard. This gives users a grace period to allow time for tokens to arrive by mail. However, users can ignore the activation process and continue to log in without using the tokens even after they arrive. This is one way to avoid second-factor authentication.

Entrust IdentityGuard lets you specify through a policy setting that new users must use their new tokens within certain period. After the date specified by the grace period, their first-factor authentication access is blocked until they activate with the token. Once they activate their tokens, they can never use just first-factor authentication again.



Deploying soft tokensTo deploy soft tokens, they must be installed and activated.

Installing the soft tokenA user must install the soft token application—either Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token—on the mobile device or computer where the token will be used. Entrust IdentityGuard Mobile is supported on a wide variety of mobile platforms including the Android, BlackBerry, iPhone, Java Phone, and Windows Mobile. Entrust IdentityGuard Soft Token is supported on Windows PCs.

There are a few ways to download and install Entrust IdentityGuard Mobile:

• users can download it to their device from the download Web site provided with the Entrust IdentityGuard Self-Service Module

• users can download it directly from the mobile device’s online app store (Apple iTunes, BlackBerry App World, Android Market, and Windows Marketplace for Mobile)

• administrators can ’push’ the software to users’ mobile devices

• the software can be downloaded through a custom method of your choosing

To install Entrust IdentityGuard Soft Token, users double-click the installation package (.msi file) and run through the installation wizard. The installation package can be made available in an email or at a network or Web location.

Activating the soft tokenAfter downloading and installing the soft token application, users activate their soft token themselves, through Entrust IdentityGuard’s Self-Service site. Activation is a simple process that involves entering a few pieces of information into the soft token application and Self-Service. See the Entrust IdentityGuard Server Administration Guide for details.

It is also possible to activate a soft token on the user’s behalf, through the Entrust IdentityGuard Administration interface; however, this method of activation requires some back-and-forth exchange of information between the soft token user and the administrator, making it a more cumbersome process than simply having the user go through Self-Service to accomplish the task.

After a soft token has been created and activated, it can be used to authenticate to your application.

147Deploying token authenticationReport any errors or omissions


148

Token securityEntrust IdentityGuard can be deployed in multiple forms, including a token deployment.

When deploying tokens, it is recommended that you:

• Do not put specific information or branding on the hardware token that will identify your site as a potential attack point if a token is lost or stolen. (It is fine to brand soft token applications such as Entrust IdentityGuard Mobile and Entrust IdentityGuard Soft Token as long as it is protected with a PIN.)

• Consider adding a feature to your application so that the application displays the user’s last successful login time and date. If this information does not match the user’s personal experience, this alerts the user that some form of attack may have occurred.

• Define a user policy and educate users on appropriate token handling to prevent users from unwittingly exposing their token data to an attacker, both physically and electronically.

• Treat token activation codes as extremely sensitive information. If intercepted, it can be used to impersonate the user.



8

Deploying knowledge-based authentication

This chapter provides deployment information for knowledge-based authentication (questions and answers). Typically, you integrate Entrust IdentityGuard with your current knowledge-based authentication application.

To make it easier for users, you can use questions and answers for additional authentication rather than for your main second-factor authentication method. For example, use machine authentication for the user’s normal login location and reserve the questions for when the user logs in from a different machine.


• “Question requirements” on page 150

• “Challenge requirements” on page 155

• “Security considerations” on page 157

Note: Many concepts discussed in the following sections were first presented by Mike Just in “Designing and Evaluating Challenge-Question Systems” IEEE Security & Privacy, vol. 02, no. 5, pp. 32-39, September-October, 2004.

149

150

Question requirementsThis section provides you with information about how to create and select a set of questions for your users to answer.


• “Sources of questions” on page 150

• “Creating good questions” on page 151

• “Selecting a set of questions” on page 153

Sources of questionsThere are several methods for developing the questions for knowledge-based authentication. The methods are discussed in Table 25.

Table 25: Methods for generating knowledge-based questions

Method Considerations

Generated codes • Examples include auto-generated PVNs, PINs, or TANs (transaction numbers)

• Represents a simple form of question

• Applies to existing users and is extremely useful for encouraging them to register for new services

Transaction data • Examples include the date and balance of a recent statement.

• Client applications must extract the data from an existing database to form the questions

• Permits an organization to use information that is already known about users as a part of knowledge-based authentication.

• Requires client applications to use the Entrust IdentityGuard Administration API (see the Entrust IdentityGuard Programming Guide for more information). This custom application executes the necessary Entrust IdentityGuard calls to import and manage the data on a per user basis. Entrust Professional Services can help organizations with this type of customizing task. For contact information, see “Obtaining technical assistance” on page 18.

Prepopulated lists • May be necessary to have users register their own questions and answers. It is recommended that your application present users with a stock list of questions from which they make selections and provide answers.

• Gives your organization control over the questions to ensure they meet criteria for privacy, security, and usability. See “Creating good questions” on page 151.



Creating good questionsThe questions you choose have a direct impact on how successful your knowledge-based authentication implementation will be. Measure the questions you select against the criteria discussed in Table 26.

User-generated • Allows users to enter their own question-and-answer challenges (not recommended).

• Users generally do not write well-formed questions.

• Users tend to forget the answers to their own questions more frequently than stock questions.

• In a design that uses multiple question-and-answer sets, it may make sense to allow one question and answer that is composed entirely by the user.

Table 26: Knowledge-based authentication criteria

Criteria Considerations

Privacy • Organizations are subject to legislation and regulations relating to the collection, storage, control, and handling of personal information.

• It is prudent to avoid personal information when building a knowledge-based authentication system.

• Construct the information collected for question-and-answer sets so that it is used exclusively for authentication purposes.

Security • Construct questions so that the answers are both difficult to obtain and difficult to guess.

• For privacy reasons, do not rely on personal information such as names, family histories and birth dates. Identity thieves regularly find or steal personal information, rendering the reliability of personal information almost useless.

• Avoid questions that have a limited number of realistic answers. For example, What is my eye color? would not require many attempts to guess a correct answer.

Table 25: Methods for generating knowledge-based questions (continued)

Method Considerations

151Deploying knowledge-based authenticationReport any errors or omissions


152

Sample questionsThe following are some examples of good questions:

Usability • Knowledge-based authentication must be simple and easy for users to use.

• The questions should have a wide applicability to the organization’s users. For example, the question What is the name of my first pet? only applies to pet owners.

• An answer must be easily recalled for the question to be useful. Questions that reflect user’s habits, regular activities, or practices generally meet this criteria.

• Answers need to remain constant for the question to be of value. Questions that prompt for a “favorite” may have different responses over time, while those that ask for a “first” should not change.

• A user must be able to enter a correct response each time. This is discussed under “Challenge accuracy” on page 155.

What is your spouse’s middle name? What is your oldest sibling’s nickname?

What is your favorite restaurant? What is your maternal grandmother’s middle name?

What is your best friend’s first name? What is your oldest child’s middle name?

Who is your favorite fictional character? What is your youngest child’s nickname?

What is the middle name of your oldest sibling?

Which sports team did you like most as a child?

What is the first name of your oldest nephew? What is your paternal grandmother’s first name?

What is your paternal grandfather’s first name? What was the first name of your favorite teacher in final year of high school?

What was the name of your first girlfriend/boyfriend?

On what street did your best friend in high school live? (enter full name of street only)

What is the first name of your spouse’s father? What is the first name of your oldest niece?

What is the first name of the Maid of Honour at your wedding?

When is your wedding anniversary? (Month and Year only)

What is the first name of the Best Man at your wedding?

What is your paternal grandfather’s middle name?

Table 26: Knowledge-based authentication criteria (continued)

Criteria Considerations



Selecting a set of questionsA common practice is to interact with the user to create several question-and-answer sets during the enrollment process. You can implement this as part of self-registration in Self-Service Module (see “Client applications” on page 38.). Then you use a randomly selected subset for subsequent knowledge-based authentication.

What is the first name of your oldest child? What is your youngest sibling’s nickname?

What was the first name of your nearest neighbor in 2000?

What is the first name of your spouse’s oldest sibling?

What was the name of your first roommate? What is your mother-in-law’s first name?

What is the middle name of your oldest sibling?

As a child, what did you want to be when you grew up?

What was your favorite college or university year?

What is your maternal grandfather’s first name?

What is the first name of the person you went to your prom with?

What is your dream job?

What is the first name of your best childhood friend?

What street did you live on when you were 10 years old?

What is the first name of your oldest niece? What is the first name of your youngest child?

What is the first name of your mother’s youngest sibling?

How old was your father when you were born? (spell out the number)

What is your favorite pizza place? What is your mother’s middle name?

What is your maternal grandmother’s first name?

What is the first name of the youngest of your siblings?

What was the make of your first car? What is your spouse’s middle name?

What was the best holiday gift that you ever received?

What street did your best friend in high school live on? (enter name of street only)

What grocery store do you shop at most often? What was the first name of your first manager?

What is your oldest sibling’s nickname? What is your favorite vegetable?

What is your father’s middle name? What was your grandfather’s nickname?

What is your favorite fruit? What is your favorite fragrance?

What is your favorite charity? What is your favorite hobby?

Where did you meet your spouse for the first time? (Enter location only)

What is the first name of your father’s youngest sibling?



154

In addition, your application (outside of Entrust IdentityGuard) can use dynamic transaction data not stored by Entrust IdentityGuard to supplement the knowledge authentication. Answers to questions such as When was your last mortgage payment? or What was your last transaction value? could be presented and validated outside of Entrust IdentityGuard. Such questions incrementally add to the overall security of the deployment.

For usability reasons, users will not tolerate answering a large number of questions for enrollment, and especially not at the time of authentication. Although you may require the user to select and answer only a few questions during authentication, it is recommended that you have a large selection of questions available. This increases the odds that each user will find an appropriate set of questions and it increases the system’s resistance to attack by making it more difficult for an attacker to anticipate a given user’s questions. It is recommended that a user answer a minimum of five questions (seven is better).

To make it easier on users, you can use questions and answers for additional authentication rather than as your main second-factor authentication method. For example, use machine authentication for the user’s normal login location and reserve the questions for when the user logs in from a different machine.



Challenge requirementsThis section focuses on the items to consider before determining what type of knowledge-based challenge best suits your security needs and your users.

Challenge sizeYou may want a different number of questions presented based on the type of access or transaction the user requires. For example, access to a company information portal could require two questions while access to a online investment site could require four questions. It is recommended that a user answer at least three questions.

You set the minimum and maximum number of required questions in Entrust IdentityGuard policy, and then set the exact number of questions for each authentication scenario in your application. Your application must present a number of questions between the minimum and maximum, and take into account the number of wrong answers allowed (if applicable).

Challenge accuracyOnce you have determined how many questions a user must answer to authenticate, you must determine how accurate a user’s answers must be.

Setting how many correct answers are requiredEntrust IdentityGuard provides flexibility in the number of questions a user must answer correctly. You can make it mandatory that all questions be answered correctly, or you can allow room for error. For example, you can determine that three out of four correct answers represents a successful authentication.

Setting the accuracy of answersBy default, Entrust IdentityGuard lets you compensate for close answers, common abbreviations and misspellings of common words (for example, “St.” and “Street”) with a word map file. You can edit this word map file over time. (For more information on the word map file, see the Entrust IdentityGuard Server Administration Guide.)

However, you can also disable the use of a word map file and require exact answers. In this case, the only leeway Entrust IdentityGuard allows is differences in punctuation, letter case, and spacing. Entrust IdentityGuard also applies a character map to support special characters (such as accented characters).



156

If you take the exact-answer approach, your application should employ the following techniques to improve the chances of receiving an exact match:

• Standardize responses.

Questions that require answers formatted in a standard way (especially dates), should include drop-down lists or other mechanisms that enforce a standardized response.

• Avoid syntactic representations.

What do you expect the answer to look like (for example, having to process “St.” as “Street”)? This requires thoughtful creation of the question. Allowing a word map (inexact answers) can eliminate most of these problems.

• Validate the answer set.

You should include rules-based post-processing of the answers given during enrollment to ensure answer quality. Your application can reject answers that do not fit your rules and prompt the user for a better answer. For example, your application should reject:

– sequential keyboard sequences (such as qwertyuiop)– repeated characters (such as aaaaaaaa)– answers that repeat the question– the same answer to different questions



Security considerationsEntrust IdentityGuard can be deployed in multiple ways, including a knowledge-based deployment.

It is recommended that your organization employ the following security precautions:

• Users should not save their questions and answers to an electronic file onto their computers or a portable device (such as a compact disc or USB drive). An attacker could use the answers in the file to impersonate the user.

• Users should not write their questions and answers on a physical medium (such as paper) where someone else can find the answers. An attacker could memorize or steal the answers to impersonate the user.

• Consider adding a feature to your application where the application displays the user’s last successful login time and date. If this information does not match the user’s personal experience, this alerts the user that some form of attack may have occurred.

• Define a user policy and educate users on appropriate knowledge-based questions and answers to prevent users from unwittingly exposing their authentication data to an attacker, both physically and electronically.



158

A

User life cycle management

This appendix provides information on the Entrust IdentityGuard user life cycle.

It contains the following sections:

• “Life cycle management overview” on page 160

• “Enrollment of users” on page 162

• “Delivery and activation” on page 165

• “Use of authenticators” on page 167

• “Renewal” on page 168

• “Replacement of authenticators” on page 170

• “Maintenance” on page 173

159

160

Life cycle management overviewThis section describes the high level processes for managing the life cycle of Entrust IdentityGuard users. If Entrust IdentityGuard is integrated with an existing user name and password authentication system, ensure that the user is created in that system first. Entrust IdentityGuard's procedures for managing users can be tied into your existing procedures.

User life cycle management consists of the following stages and processes:

• enrollment

This is the initial stage where users enroll for the Entrust IdentityGuard service. See “Enrollment of users” on page 162.

• delivery and activation

This describes the processes to physically deliver Entrust IdentityGuard grid cards, passcode lists, tokens, and smart credentials and activate the authentication method for each user. It does not apply to the nonphysical authentication methods, such as soft tokens, knowledge-based questions and answers, or one-time passwords. See “Delivery and activation” on page 165.

• usage

This is the normal operations stage where users log in to your organization through Entrust IdentityGuard. See “Use of authenticators” on page 167.

• renewal

This is an ongoing stage where users are issued new Entrust IdentityGuard grids (on new cards), tokens, personal verification numbers (PVN), certificates, smart credentials, or questions to replace older ones. See “Renewal” on page 168.

• replacement

This covers the handling of:

– lost, stolen, damaged, and misplaced Entrust IdentityGuard grid cards, passcode lists, hardware tokens, or smart credentials

– forgotten answers and PVNsUsers are issued temporary PINs (if using grid cards, lists, or hardware tokens), or receive replacement Entrust IdentityGuard grid cards, passcode lists, hardware tokens, or smart credentials. See “Replacement of authenticators” on page 170.

• maintenance

This describes the processes to:

– Remove stale or idle grid cards or tokens from the Entrust IdentityGuard system. This includes grid cards, lists or tokens that are canceled, never



activated, or unassigned, as well as those assigned to terminated user accounts.

– Update graphics or images used for organization authentication.– Update personal verification numbers (PVN).– Update IP geographical data.See “Maintenance” on page 173.

161User life cycle managementReport any errors or omissions


162

Enrollment of usersEnrollment is the first stage of the life cycle.

This topic includes the following:

• “Enrolling users” on page 162

• “Enrolling smart credential users” on page 163

Enrolling usersDuring the enrollment stage:

• Users are registered in the Entrust IdentityGuard system.

• Users are assigned an Entrust IdentityGuard authentication method (such as a grid card or token) and provided with the physical form factor associated with the specified authentication type. For soft tokens, users are given instructions on how to obtain the Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token software.

• Users activate the authentication method.

The easiest way to ensure efficiency and consistency in user enrollment is to have users self-register using Entrust IdentityGuard Self-Service. You set up the self-registration requirements and flow, and provide users with a user name and password. Users log in to Self-Service using the user name and password, and follow the steps to create their account, register for the authentication types they need, and download whatever software they need (the Entrust IdentityGuard Mobile soft token application, for example).

With or without Entrust IdentityGuard Self-Service Module, you must ensure you have processes and procedures in place to create and manage user accounts and to issue the authentication credentials (such as user names and passwords). Depending on the authentication methods assigned to users, the following are examples of events that may occur:

• Entrust IdentityGuard grids are assigned to users and Entrust IdentityGuard grid cards are produced.

• Microsoft Windows desktop users install Entrust IdentityGuard Desktop for Microsoft Windows.

• Tokens are assigned to users and mailed to them, along with activation instructions.

• Users download Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token and activate their soft token through Self-Service.

• Users are directed to a Web page where they go through a registration process that sets up the questions and answers specific to them.

• Computers are registered.



• Certificates are associated with users.

To make sure new grid card, token, and soft token users enroll promptly, use the search function in the Administration interface to find users whose activation grace period is about to expire. See “Forcing grid card activation” on page 134 for more information. The same mechanism applies to tokens and soft tokens.

If you are using grid cards, passcode lists, or tokens, complete the enrollment process with “Maintenance” on page 173.

Enrolling smart credential usersDuring the enrollment stage:

• For smart credential users, enrollment depends on whether the smart credential is going to be personalized (smart credential holder information encoded on the card) or unpersonalized:

– Personalized: If the smart credential is going to be personalized, enrollment is performed through the Enrollment Module, where biographical information and biometric information is collected. Enrollment Module also enrolls the user within IdentityGuard if the user does not already exist.

– Unpersonalized: If the smart credential simply consists of a pre-encoded applet (encoding performed by Entrust), and no personal data, Enrollment Module is unnecessary. Administrators can either enroll the user within IdentityGuard (smart credential users require an IdentityGuard user entry) or Self-Service Module can be configured to allow the user to create their own IdentityGuard user entry.

• Users are provided with the physical form factor associated with the specified smart credential (such as a smart card or USB token).

• The smart credential is activated. Activation can be performed by an administrator or user. If an administrator is personalizing a smart credential, activation is automatically performed at the same time as printing or encoding though the Print Module. If a user receives an unpersonalized smart credential, they can activate it through Self-Service Module (if configured).

User enrollment from LDAP user repositoryIf user entries exist in an LDAP repository, you can use the user enrollment function to create Entrust IdentityGuard user accounts in specific groups that you choose.

User enrollment is a bulk process that you set up in Entrust IdentityGuard, either through the Administration interface or from the master user shell. When you run the operation that creates user accounts for new user entries in your LDAP directory, you can choose whether to load them all, or choose which to load, as the process runs.



164

You can use the Entrust IdentityGuard user enrollment feature in one of two ways. When you are first deploying Entrust IdentityGuard, or if you are introducing a new LDAP repository full of new users, you can run user enrollment to load all users from the LDAP repository to Entrust IdentityGuard.

You can also run user enrollment process once a day or once a week, for example, to create Entrust IdentityGuard records for any users recently added to the LDAP repository by filtering for the new user records—those not yet created in Entrust IdentityGuard.

If you are using the Self-Service Module, you can have user entries created on an as-needed basis in Entrust IdentityGuard as users register through Self-Service.



Delivery and activation

Note: This section does not apply to soft tokens.

Delivery and activation processes are common to the enrollment, renewal and replacement life cycle stages for cards (grids and passcode lists), tokens, and smart credentials. After Entrust IdentityGuard authentication data (new, renewal or replacement) has been produced, it must be delivered to the rightful owner and activated.

The physical distribution of authentication data requires both distribution and inventory management processes. The specific requirements depend on whether the grid cards, tokens, or smart credentials will be picked up in person, mailed out, delivered by courier, or a combination of these delivery methods.

For each of these options, distribution may be centralized into one location, to a few locations such as regional offices, or many locations such as branch or retail centers. Appropriate security and tracking processes should be in place for physical distribution and for managing inventory.

Figure 32 illustrates the high level process steps for delivery and activation.

Figure 32: Delivery and activation of authenticators

To deliver and activate a user’s authentication data

1 Grid cards, passcode lists, tokens, and smart credentials can be delivered in two ways:

• using an over-the-counter service for immediate service

This involves an in-person pickup.

• using a central service that responds to user requests

Administrators can be given the option of mailing the grid card, token, or smart credential directly to the user.

2 If you are using a central service, the user must visit the service desk to obtain their authenticator. You can require the service desk to verify the person’s identity



166

to ensure that the card, token, or smart credential is delivered to its rightful owner.

3 Activate the authenticator. You can use an over-the-counter approach or a self-activation approach employed by the Self-Service Module.

Note: Personalized smart credentials are automatically activated during the encoding and/or printing process through Print Module.

• In an over-the-counter approach, the administrator can activate the authenticator immediately before handing it to the user.

• In one self-activation approach, the user initiates the activation by completing an authentication transaction. This applies to cards and tokens only, and is as simple as using the Entrust IdentityGuard card or token on the next login.

• Using the Self-Service Module user interface, the user can log in to activate the card, token, or (unpersonalized) smart credential.

For the activation procedures you deploy, take into account the requirements for replacement (see “Replacement of authenticators” on page 170).



Use of authenticatorsDuring the usage stage, users are actively logging into your system using the authentication methods available to them.

The Entrust IdentityGuard system locks out a user after a configured number of incorrect responses to a challenge (for example, three incorrect responses). This is necessary to protect against a brute force attack in which an attacker attempts to log in by repeatedly guessing an Entrust IdentityGuard challenge.

However, a legitimate user can be locked out by making consecutive errors. By default, the Entrust IdentityGuard system locks out the user permanently, and an administrator must unlock them. Organizations should design their help desk procedures for this situation to ensure that proper identity verification is performed before unlocking an user’s account.



168

Renewal

Note: The concept of renewal does not apply to soft tokens or smart credentials. For soft tokens, users simply download and activate a new soft token if they need a new one for whatever reason. For smart credentials, administrators would reissue or replace a smart credential if lost or expired, which may require modification of enrollment data (if the smart credential is personalized).

You should ensure users renew their authentication data (such as their passwords, tokens, grids, PVNs, and knowledge-based information) on a regular basis. Once the data expires or exceeds a usage period, make sure users are able to renew the data promptly so that they are not denied service.

Ensure you put a process in place that completes the following actions (when applicable) before expiry:

• a new grid, passcode list, or token is issued and delivered to the user

• a user is redirected to a page that requests new knowledge-based information

• users are directed to change their PVN

An automated central renewal service such as Self-Service Module is recommended so that you do not have to burden your staff with the overhead of administering routine renewals.

Figure 33 illustrates the high level process steps for renewal.

Figure 33: Renewal of authenticators

To renew a user’s authentication data

1 Extract information from the Entrust IdentityGuard repository using the reporting feature, selecting users whose Entrust IdentityGuard authentication data will expire within a specified time frame. This should be done on a regularly scheduled basis.

2 Generate and assign new authentication data.

• For grids and passcode lists, Entrust IdentityGuard generates and assigns new authentication data for each selected user name.

• For tokens, administrators assign a new token to the user.



• For knowledge-based information or image/graphic replay authentication, an application requests new information from a user when they log in.

3 If applicable, produce new grid cards, passcode lists, and smart credentials, or order more tokens.

Grid card production is discussed in detail in the section “Deploying grid authentication” on page 121.

4 If you are using grid cards, passcode lists, or tokens, complete the renewal process with “Maintenance” on page 173.



170

Replacement of authenticatorsEntrust IdentityGuard authentication data and devices may be misplaced, lost, stolen, forgotten, damaged or left behind. Therefore, to ensure users are not inconvenienced, it is important to have contingency measures in place to provide users with the access they need until replacement data is in their possession.

An easy and cost-effective way to solve the issue of replacement authenticators is to use the Entrust IdentityGuard Self-Service Module. The Self-Service Module provides a completely customization Web site through which users can request and obtain replacement authenticators as well perform a wide variety of other administrative tasks. For details, see “Entrust IdentityGuard Self-Service Module” on page 32.

Figure 34 illustrates the high level process steps for replacement.

Figure 34: Replacement of authenticators

To replace a user’s authentication data

1 A user needs to verify their identity and start the recovery process. There are three approaches:

• over-the-counter recovery (identity verification)

In the over-the-counter approach, the user visits the service desk and requests replacement authentication data. The service desk performs in-person identity verification to ensure that the request is legitimate. This approach is useful where a visit to the service desk is mandatory (for example, the Entrust IdentityGuard grid is printed on the back of an employee ID card).



• self-service recovery (identity verification)

In the self-service approach, the user has access to a self-recovery application. The application performs an identity verification procedure, possibly using knowledge-based authentication, to ensure that the request is legitimate. The questions and answers for recovery must have been created by the user during the enrollment process or through a separate application after enrollment. Entrust provides a self-service application (“Entrust IdentityGuard Self-Service Module” on page 32) for use with Entrust IdentityGuard so that you do not have to write your own.

• central service recovery (identity verification)

In the central service approach, the user calls the service desk and requests recovery of the authentication data. The service desk performs identity verification over the phone to ensure that the request is legitimate.

2 The application or service desk administrator provides a user with a temporary authentication method. If provided by an application, ensure that the information is displayed in nonmachine-readable format.

• If using grid, token, or soft token authentication, the administrator or application should cancel the current authenticator and provide the user with a temporary PIN with which to authenticate while they wait for their new authenticator, or new mobile device (in the case of Entrust IdentityGuard Mobile soft tokens). Cancelation is recommended for lost, stolen and damaged grid cards, tokens, and soft tokens. A “left behind” authenticator (for example, the user knows where the grid card is, and it is safe from attack) can be temporarily suspended.

For information on temporary PINs, see “Temporary PIN authentication” on page 78.

Attention: The cancellation process is irreversible for grid cards, passcode lists, tokens, and soft tokens. Once they are canceled, they can never be used again.

• If using out-of-band authentication, a one-time password should be generated. A one-time password expires when used, or at the time specified by policy, whichever comes first.

• If using knowledge-based authentication, give hints that the user provided during registration. If the hints do not help, issue a one-time password or temporary PIN so the user can complete the recovery process.

3 Determine whether you need to replace or recover the authentication data.

• For grid cards, passcode lists, and tokens, the user may indicate whether replacement or re-activation is necessary. If you cancel the grid card, list, token, then you must replace it. Ensure the temporary PIN is canceled when



172

the user has successfully authenticated using a re-activated or new grid card, list, or token.

• For soft tokens, if the computer or mobile device on which the soft token is installed becomes unavailable (because it is lost, damaged, or otherwise unusable), the user must reinstall the soft token application (either Entrust IdentityGuard Soft Token or Entrust IdentityGuard Mobile) on their new computer or mobile device and go through the activation process again. If the soft token application itself becomes unusable, but the computer or device on which it is installed is intact, users can simply reactivate the soft token without reinstalling the software.

• If using knowledge-based or image replay authentication, it is recommended that, if the information is permanently forgotten, the user reset their information through a secure Web page (such as one located on your Intranet). Optionally, they can enter a temporary PIN to verify their identity when accessing the page, or call an administrator to complete the process.

• For smart credentials, if a user loses a smart credential or the smart credential is stolen, cancel the existing card (so that certificates are revoked) and then issue a new smart credential to the user. You cannot re-issue the same document and must perform a card replacement. If a user forgets a smart credential, you can issue a temporary smart credential to the user and put the user’s current smart credential on hold until the user brings it back. If you issue personalized smart credentials, the temporary smart credential should be unpersonalized.

If you are using grid cards, passcode lists, tokens, or smart credentials, complete the replacement process with “Maintenance” on page 173.



MaintenanceMaintenance procedures are required to remove stale or idle data from the Entrust IdentityGuard system. Ensure that an Entrust IdentityGuard administrator regularly performs the following maintenance tasks.

Remove canceled grid cards and tokensGrid cards, tokens, and soft tokens that have been canceled should be removed from the Entrust IdentityGuard system periodically. This removal is particularly important for soft tokens, because it frees up user licenses which can then be re-used.

Canceled authenticators can never be used again. However, the associated information is retained in the repository. You should establish policies for:

• the archival and removal of canceled grid cards, tokens, and soft tokens on a periodic basis

• whether or not archives need to be retained and, if so, for how long

Remove canceled smart credentialsSmart credentials that have been canceled should be removed from the Entrust IdentityGuard system periodically. Removing smart credentials from Entrust IdentityGuard frees up smart credential licenses which can then be re-used.

One consideration is whether the card can be re-used or not. If you use personalized smart credentials—such as smart cards with employees’ names and pictures—you cannot re-use the smart credentials. For non-personalized smart credentials, they can be used by another user. To re-use a smart credential, you would unassign the card or token to the unassigned pool and then delete the user smart credential.

Remove inactive grid cards and tokensOrganizations should not encounter many Entrust IdentityGuard grid cards or hardware tokens that were never activated, although they can get lost in transit. Users are expected to notify the service desk in such circumstances. A replacement grid card or token would be issued and the inactive grid card or token canceled.

It is also unlikely that there will be many inactive soft tokens in your system considering that the user creates and activates the soft token in one shot. Still, if a soft token exists in Entrust IdentityGuard that has not been activated, users can activate it through Self-Service at any time, or an administrator can cancel the token.

The Entrust IdentityGuard administrator can check for items that were never activated on a periodic basis to ensure that they are either activated by the rightful owner or canceled.



174

Remove unassigned grid cards and tokensTokens and grid cards added in the preproduction model are initially unassigned. The Entrust IdentityGuard administrator, in conjunction with the service desk, should perform an inventory check on a periodic basis to identify any lost grid cards and tokens and cancel them. It is expected that the service desk will maintain proper inventory control and that few unassigned grid cards or tokens, if any, will be lost.

(There is no need to perform a periodic check for unassigned soft tokens, because they do not exist. A soft token is always assigned to a user.)

Synchronize with the repositoryCoordinate maintenance activities between the Entrust IdentityGuard administrator and the repository administrator. In particular, when user accounts are terminated, the associated Entrust IdentityGuard information should be removed.

For information about creating new Entrust IdentityGuard users by synchronizing your LDAP repository with Entrust IdentityGuard, see “User enrollment from LDAP user repository” on page 163.

Update images used for mutual authenticationYou should occasionally change the images users can select for image-replay mutual authentication. This makes it harder for attackers to spoof your site.

Update personal verification numbersEach personal verification number (PVN) includes a last-used date. You can check this date to find a list of users whose PVNs need replacing. You should require users to change their PVN on a regular basis.

Update IP geographical dataYou can download new IP lists from Entrust. See the Entrust IdentityGuard Server Administration Guide for more information about updating IP data files.



B

Entrust IdentityGuard baseline architectures

This section outlines some baseline architectures and complements the information about architecture and deployment provided in the other guides in the Entrust IdentityGuard documentation suite.

See the Entrust IdentityGuard Server Administration Guide for more information on the authentication issues that influence the choice of architecture and configuration of your Entrust IdentityGuard solution.

Note: Entrust Professional Services can provide more information on an architecture suitable to your requirements. For contact information, see “Obtaining technical assistance” on page 18.

This appendix contains the following sections:

• “Architecture overview” on page 177

• “Web access architectures” on page 179

• “VPN remote access architectures” on page 183

• “Wireless access architectures” on page 187

• “Microsoft Windows remote access architectures” on page 190

• “Generic remote access architectures” on page 194

• “Microsoft Windows desktop architectures” on page 198

• “Pluggable Authentication Module (PAM) Plug-in architectures” on page 202

• “Self-Service architectures” on page 203

• “Federation Module architectures” on page 211

175

176

• “Enrollment Module architectures” on page 216

• “Print Module architectures” on page 218

• “Mobile enrollment architecture” on page 220



Architecture overviewThere are three levels of baseline architecture in this section: evaluation, standard and high availability.

Evaluation architectureEvaluation-level architecture:

• suits test and proof-of-concept environments

• is designed to be low cost to implement, by minimizing the required equipment

• represents a limited environment that you can set up quickly for proof-of-concept, investigation of functionality, and so on

• is not intended for production purposes

Assumptions:

• generally very small, ranging from a few users up to a hundred users

• used for test purposes only

• no firewalls

• no NTP service; clock is set manually

• typically resides within a development environment, or on an isolated network segment

Standard architectureStandard-level architecture:

• suits production implementations from pilot phase through initial rollout

• lacks equipment redundancy; any standard environment should be implemented with robust equipment to provide a moderately high level of availability and performance

• represents production environments suitable for a medium volume environment

• is more complex to set up than the evaluation architectures because of firewalls and other security provisions

• uses separate servers for each function to support higher throughput

Assumptions:

• support for internal or external users

• generally moderate in size, supporting tens of thousands of users

• multiple firewalls create zones for increasing levels of security

177Entrust IdentityGuard baseline architecturesReport any errors or omissions


178

• limited provision for failover

• a backup strategy is in place to ensure that the data stores and system disks can be rebuilt in the event of a hardware failure (add a disk mirroring strategy to reduce recovery time in the event of a disk failure)

• an NTP service, connected to a trusted time source (such as a Stratum 1 or Stratum 2 time server), is available to ensure clock accuracy for tokens (some downtime is acceptable; no provision is made for replicated systems)

• network architecture already in place

High availability architectureHigh availability architecture:

• suits large scale production implementations that demand the highest levels of availability and performance

• expands upon the standard configurations by adding redundancy for both high availability and scalability

• is intended for production purposes in a high volume environment, whether supporting internal or external users

Assumptions:

• offers higher throughput than standard baseline architectures

• includes redundant systems, links, trusted time sources, and data stores

• is more complex to set up because of the significant provision for security, performance, and availability

• deployments are generally large, supporting millions of users

• uses load-balancers to achieve high availability for Entrust IdentityGuard



Web access architecturesYou can deploy the Web access baseline architecture in an evaluation, standard or high availability environment.

You can use any Entrust IdentityGuard authentication method when your users access your organization using their Web browsers.

Web access - evaluation architectureFigure 35 illustrates how you can set up Entrust IdentityGuard to provide multifactor authentication for your Web resources.

Figure 35: Web authentication evaluation architecture

Requirements• directory or database with user repository

• Entrust IdentityGuard Server

• Web server or application server running an application that controls first-factor authentication (user name and password) and manages the repository

• client with Web browser



180

Web access - standard architectureThe standard architecture, shown in Figure 36, extends the evaluation architecture (“Web access - evaluation architecture” on page 179) by:

• adding firewalls that provide network segmentation for the authentication and application systems

• adding separate servers for the Web server and application server (consistent with best practice for security, availability and performance)

• adding a separate computer containing the Entrust IdentityGuard Administration interface where administrators manage users

Figure 36: Web access standard architecture

Requirements• directory and/or database on a dedicated server for the user repository


• application server running an application that completes first-factor authentication (user name and password) and manages the repository (Entrust IdentityGuard can manage first-factor authentication if required)

• hard and soft firewalls creating a DMZ (demilitarized zone) for the Web server, and protecting internal resources



• Web server located in DMZ that relays information between the client, the application server, and Entrust IdentityGuard Server


• an administrator to manage Entrust IdentityGuard users

Web access - high availability architectureThe architecture shown in Figure 37, extends the standard architecture (“Web access - standard architecture” on page 180) by adding load-balancers, replica Entrust IdentityGuard Servers, and replicated user repositories. It is expected that the network components (for example, routers, firewalls, and so on), Web servers and application servers are configured to provide high availability and performance.

Figure 37: Web access high availability architecture



182

Requirements• replicated directories and/or databases for the user repository, set up in a

high availability or disaster recovery cluster

• Entrust IdentityGuard Servers

• load-balancers to divide the load among the various Entrust IdentityGuard Servers

• replicated application servers that complete first-factor authentication (user name and password) and manage the repository (alternatively, Entrust IdentityGuard can manage first-factor authentication if required)

• hard and soft firewalls creating a DMZ (demilitarized zone) for the Web servers, and protecting internal resources

• replicated Web servers located in DMZ that relay information between the client, the application server, and Entrust IdentityGuard Server


• administrators to manage Entrust IdentityGuard users



VPN remote access architecturesYou can deploy the VPN remote access baseline architecture in an evaluation, standard or high availability environment.

You can use any of the following Entrust IdentityGuard authentication methods when your users access your organization through VPN:

• grid authentication

• token authentication

• Entrust IdentityGuard password (first-factor) authentication

• one-time password authentication

• knowledge-based authentication

• risk-based authentication

VPN remote access - evaluation architectureUse this architecture to evaluate how Entrust IdentityGuard can integrate with your current VPN solution to provide multifactor authentication to remote users.

Figure 38: VPN remote access evaluation architecture



184

Requirements• directory or database with user repository

If using a database, you can install it on the same computer as the one hosting Entrust IdentityGuard Server.


• Entrust IdentityGuard Radius proxy, configured on the same computer as the Entrust IdentityGuard Server

• a first-factor authentication resource, such as a Remote Authentication Dial In User Service (Radius) server, a domain controller, or an LDAP-compliant directory (see “External authentication” on page 48); optionally, Entrust IdentityGuard can also manage first-factor authentication

• VPN device (IPsec or SSL)

• client with VPN connection (dial-up, wireless, and so on)

VPN remote access - standard architectureThe standard architecture, shown in Figure 39, extends the evaluation baseline architecture by adding firewalls (which provide network segmentation for the authentication systems) and user administration.

Figure 39: VPN remote access standard architecture





• Entrust IdentityGuard Radius proxy, configured on the Entrust IdentityGuard Server computer

• a first-factor authentication resource, such as a Radius server, a domain controller, or an LDAP-compliant directory (see “External authentication” on page 48); optionally, Entrust IdentityGuard can manage first-factor authentication

• VPN device (IPsec or SSL)

• client with VPN connection (dial-up, wireless, and so on)

• hard and soft firewalls creating a DMZ (demilitarized zone) for the VPN device, and protecting internal resources


VPN remote access - high availability architectureThe architecture in Figure 40 on page 186 extends the standard VPN remote access configuration (“VPN remote access - standard architecture” on page 184) by adding load-balancers, replica Entrust IdentityGuard Servers, and replicated user repositories.

The network components (for example, VPN devices, routers, firewalls, and so on) and first-factor authentication resources must be configured to provide high availability and performance.



186

Figure 40: VPN remote access high availability architecture

Requirements• replicated directories and/or databases for the user repository, set up in a

high availability or disaster recovery cluster



• Entrust IdentityGuard Radius proxies, configured on the Entrust IdentityGuard Servers

• a cluster of first-factor authentication resources, such as Radius servers, domain controllers, or LDAP directories (see “External authentication” on page 48); optionally, Entrust IdentityGuard can manage first-factor authentication

• VPN devices (IPsec or SSL)

• clients with VPN connection (dial-up, wireless, and so on)

• administrators to manage Entrust IdentityGuard users

• hard and soft firewalls creating a DMZ (demilitarized zone) for the VPN devices, and protecting internal resources



Wireless access architecturesThis architecture is not dependent on a specific platform for the access server. It only requires that you have a wireless access point. You can deploy the wireless access baseline architecture in an evaluation, standard, or high availability environment.

Since this architecture includes the Radius proxy, you can use these second-factor authentication methods: grid, token, temporary PIN, OTP, and one question-and-answer challenge. The token method can include a personal verification number (PVN) challenge.

See Entrust IdentityGuard Server Administration Guide for supported deployments and implementation details.

Wireless access - evaluation architectureUse this architecture to evaluate how Entrust IdentityGuard can provide multifactor authentication for wireless users.

Figure 41: Wireless access evaluation architecture

LDAP or database repository

Entrust IdentityGuard Server with Radius

proxy

Wireless access point

EAP supplicant

Requirements• wireless access point

• LDAP directory or database user repository



188

• Entrust IdentityGuard Server and the Radius proxy

Wireless access - standard architectureThe architecture shown in Figure 42 extends the evaluation architecture by adding user administration so that you can provide multifactor authentication to wireless users in your organization.

Figure 42: Wireless access standard architecture

Firewall

EAP supplicant

AdministratorEntrust IdentityGuard Server with Radius

proxy

Access server supporting RAS and

EAP

Distributed LDAP or database repository


• distributed LDAP directory or database user repository





Wireless access - high availability architectureThe architecture shown in Figure 43 adds load-balancers, replica Entrust IdentityGuard Servers, and replicated user repositories. It is assumed that network components (access servers, routers, firewalls, and so on) and first-factor authentication resources are configured to provide high availability and performance.

Figure 43: Wireless access high availability architecture

Entrust IdentityGuardServer with Radius

proxy

Administrator

Firewall


proxy


Load -balancing cluster

Wireless access point

EAP supplicant


• replicated and distributed LDAP directory or database user repository

• multiple Entrust IdentityGuard Servers with the Radius proxy




190

Microsoft Windows remote access architectures

You can deploy the Microsoft Windows remote access baseline architecture in an evaluation, standard or high availability environment.

You can use the grid, token or temporary PIN authentication methods when your users access your organization remotely through Microsoft Windows.

Microsoft Windows remote access - evaluation architectureUse this architecture to evaluate how Entrust IdentityGuard can add multifactor authentication for Microsoft Windows remote users.

Figure 44: Microsoft Windows remote access evaluation architecture

Requirements• Active Directory with user repository

• Domain controller (you can install it on the same machine as the user repository)




• Microsoft Routing and Remote Access Service (RRAS) with Internet Authentication Service (IAS)

• Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on RRAS computer

• client with Microsoft Remote Access capabilities

Microsoft Windows remote access - standard architectureThe Microsoft Windows remote access standard architecture, shown in Figure 45, extends the evaluation architecture by adding firewalls and user administration so that you can provide multifactor authentication to the Microsoft remote users in your organization.

Figure 45: Microsoft Windows remote access standard architecture

FirewallFirewall

Microsoft Remote Access Client

Administrator Entrust IdentityGuard Server

Microsoft RRAS with Entrust IdentityGuard

Remote Access Plug-in

Distributed domain with Active Directory

Requirements• distributed domain configuration with user repository




192


• Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on the IAS computer


• hard and soft firewalls creating a DMZ (demilitarized zone) for the RRAS, and protecting internal resources


Microsoft Windows remote access - high availability architecture

The architecture in Figure 46 on page 193 extends the standard Microsoft Windows remote access configuration (“Microsoft Windows remote access - standard architecture” on page 191) by adding load-balancers, replica Entrust IdentityGuard Servers, and replicated user repositories.

The network components (for example, access servers, routers, firewalls, and so on) and first-factor authentication resources must be configured to provide high availability and performance.

Note: In any remote-access configuration shown in this section, you can set up an architecture in which the IAS is enabled on a different computer than the RRAS is. In that instance, you need to install the Remote Access Plug-in on the computer hosting the IAS.



Figure 46: Microsoft Windows remote access high availability architecture

Requirements• distributed domain configuration with replicated user repository


• load-balancers to divide the load between the Entrust IdentityGuard Servers


• Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on the IAS computer


• hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote Access Server, and protecting internal resources




194

Generic remote access architecturesThis architecture is not dependent on a specific platform for the access server. It only requires that your remote client and access server support the Extensible Authentication Protocol (EAP). You can deploy the generic remote access baseline architecture in an evaluation, standard or high availability environment.

Since this architecture includes the Radius proxy, you can use these second-factor authentication methods: grid, token, temporary PIN, OTP, and one question-and-answer challenge. The token method can include a personal verification number (PVN) challenge.

Generic remote access - evaluation architectureUse this architecture to evaluate how Entrust IdentityGuard can provide multifactor authentication for remote users.

Figure 47: Generic remote access evaluation architecture

LDAP or database repository

Entrust IdentityGuard Server with Radius

proxy


EAP

Windows EAP client

Requirements• an LDAP directory or database user repository


• access server supporting Remote Access Service (RAS) and EAP



• remote Microsoft Windows client supporting EAP

Generic remote access - standard architectureThe architecture shown in Figure 48 extends the evaluation architecture by adding a firewall and user administration so that you can provide multifactor authentication to remote users in your organization.

Figure 48: Generic remote access standard architecture

Requirements• distributed LDAP directory or database user repository




• hard and soft firewalls creating a DMZ (demilitarized zone) for the RAS, and protecting internal resources



196


Generic remote access - high availability architectureThe architecture shown in Figure 49 adds load-balancers, replica Entrust IdentityGuard Servers, and replicated user repositories. It is assumed that network components (access servers, routers, firewalls, and so on) and first-factor authentication resources are configured to provide high availability and performance.

Figure 49: Generic remote access high availability architecture


proxy

Administrator

Firewall


proxy




EAP

Firewall

Windows EAP client

Requirements• replicated and distributed LDAP directory or database user repository

• multiple Entrust IdentityGuard Servers with the Radius proxy



• load-balancers to divide the load among the Entrust IdentityGuard Servers



• hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote Access Server, and protecting internal resources




198

Microsoft Windows desktop architecturesYou can deploy the Microsoft Windows desktop baseline architecture in an evaluation, standard or high availability environment.

You can use the grid, token or temporary PIN authentication methods when your users access your organization through their Microsoft Windows desktop.

Microsoft Windows desktop - evaluation architectureThis architecture (shown in Figure 50) demonstrates how you can use Entrust IdentityGuard to provide multifactor authentication to Microsoft Windows users when they log in to their computer.

Figure 50: Microsoft Windows desktop authentication evaluation architecture

Requirements• Active Directory with user repository

• domain controller (you can install it on the same machine as the user repository)




• Entrust IdentityGuard Desktop for Microsoft Windows installed on a computer

Microsoft Windows desktop - standard architectureThe Microsoft Windows desktop standard architecture, shown in Figure 51, extends the evaluation architecture by adding a firewall and user administration so that you can provide multifactor authentication to the desktop users in your organization.

Figure 51: Microsoft Windows desktop standard architecture

Requirements• distributed domain configuration with user repository


• firewall

• Entrust IdentityGuard Desktop for Microsoft Windows installed on users’ computers




200

Microsoft Windows desktop - high availability architectureThe high availability grade baseline architecture, shown in Figure 52, extends the standard grade baseline architecture by adding load-balancers and replica Entrust IdentityGuard Servers, and replicated user repositories.

It is expected that the network components (for example, routers, firewalls, and so on) and domain controllers will be configured to provide high availability and performance.

Figure 52: Microsoft Windows desktop authentication high availability architecture

Entrust IdentityGuard

Entrust IdentityGuard Desktop for Microsoft

Windows

Administrator

Firewall

Entrust IdentityGuard

Distributed domain with Active Directory


Requirements• distributed domain configuration with replicated user repository



• firewall



• Entrust IdentityGuard Desktop for Microsoft Windows installed on user’s computers or laptops




202

Pluggable Authentication Module (PAM) Plug-in architectures

The Entrust IdentityGuard Pluggable Authentication Module (PAM) Plug-in integrates a UNIX or Linux server with Entrust IdentityGuard so that you can add second-factor authentication to common UNIX (Solaris) and Linux services like ssh. The PAM Plug-in works with existing UNIX first factor authentication services such as NIS, LDAP, and Kerberos.

You can also use the PAM Plug-in in a high-availability scenario with multiple Entrust IdentityGuard servers.



• Entrust IdentityGuard Radius proxy, configured on the Entrust IdentityGuard Server computer

• UNIX Server(s) with Entrust IdentityGuard PAM Plug-in installed

• client with connection to UNIX server




Self-Service architecturesAs part of the Entrust IdentityGuard product line, you can purchase the Entrust IdentityGuard Self-Service Module. This product is a client of the Entrust IdentityGuard Server. Its main purpose is to provide a Web interface through which end users can perform administrative tasks against their Entrust IdentityGuard accounts—tasks that would normally be completed by an administrator.

Here are just a few of the tasks that users can perform through Self-Service:

• Create an Entrust IdentityGuard account.

• Request a new grid, token, or soft token.

• Change their password.

• Add or change contact information.

• Download Entrust IdentityGuard Mobile to their mobile device.

• Download Entrust IdentityGuard Soft Token to their PC.

Aside from self-service, the Self-Service Module also includes transaction verification functionality for users who have Entrust IdentityGuard Mobile. See “Transaction verification” on page 79 for details.

You can deploy the Self-Service Module in the following standard architectures:

• consumer, see “Self-Service - consumer architecture” on page 203

• enterprise, see “Self-service - enterprise architecture” on page 205

• soft token, see “Self-service - soft token architecture” on page 207

• multi-node, see “Self-service - high availability architecture” on page 209

Self-Service - consumer architectureThe consumer architecture is typically used for online banking applications and other Web-based applications where your user base resides exclusively outside your organizational boundary. Notice that Self-Service is exposed to the Internet, so any user can attempt to log in to your Self-Service application.

For details on these components, see the Entrust IdentityGuard Self-Service Module Installation and Configuration Guide.



204



• Self-Service Module, with the Self-Service component deployed, at a minimum. The download component is only required if you are deploying a soft token application such as Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token, and want to enable a download site from which to obtain the application. (The download site is mandatory if you want to use the Java Phone version of Entrust IdentityGuard Mobile.) The transaction component is only required if you want to enable the transaction verification feature (see “Transaction verification” on page 79 for details).

• an authentication application that makes use of the Entrust IdentityGuard API to deliver second-factor authentication

• a connection to the Entrust Notification Service, which is a Web service hosted by Entrust. This is an optional connection, and is only required if you



are deploying Entrust IdentityGuard Mobile with the transaction notifications (pop-up alerts), which is a sub-feature of the transaction verification feature.


• Web server in the DMZ. This Web server:

– must have Tomcat AJP connector installed and configured to connect to the AJP connector on the Self-Service ModuleOR

– must redirect requests on the standard HTTPS and HTTP ports to the Self-Service Module’s non-standard ports (8445 and 8081).

• a user with a browser, and optionally, a second-factor authenticator such as a soft token, token, or grid.

• an administrator, to configure Self-Service and perform administration functions that are not available through Self-Service.

Self-service - enterprise architectureThe enterprise architecture is typically used with VPN applications, Outlook Web Access (OWA), or any remote-access applications that let your employees access your internal network from home or on the road.

Notice that Self-Service is only available from within your organizational boundary. This means that users must physically be in the office (or must VPN in to your network) before they can log in to the Self-Service application to perform self-service actions such as changing their PIN and so on.

If you want to make Self-Service available externally, see instead “Self-Service - consumer architecture” on page 203.



206

Requirements• directory and/or database on a dedicated server to contain Entrust

IdentityGuard user accounts


• a Self-Service Module with the Self-Service component installed.


• a user with a browser and a second-factor authenticator such as a hardware token or grid. If your users have Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token, see instead “Self-service - soft token architecture” on page 207.

• an administrator, to configure Self-Service and perform administration functions that are not available through Self-Service



Self-service - soft token architectureThe soft token architecture presented below is used if you want to deploy Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token externally, and offer Self-Service internally. If Self-Service over the Internet is acceptable, then the consumer architecture (“Self-Service - consumer architecture” on page 203) can be used as your soft token architecture.

Notice that:

• Self-Service is only available from within your organizational boundary. This means that users must physically be in the office (or must VPN in to your network) before they can log in to the Self-Service application to perform self-service actions such as changing their PIN and so on.

• The download and transaction components are hosted in the Demilitarized Zone (DMZ) to make them accessible to users who are outside your organizational boundary.

For details on these components, see the Entrust IdentityGuard Self-Service Module Installation and Configuration Guide.



208


IdentityGuard user accounts


• two Self-Service Module installations: one with the Self-Service component installed, and the other with the download and transaction components installed. The download component is only required if you are deploying a soft token application such as Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token, and want to enable a download site from which to obtain the application. (The download site is mandatory if you want to use the Java Phone version of Entrust IdentityGuard Mobile.) The transaction component is only required if you want to enable the transaction verification feature (see “Transaction verification” on page 79 for details). If you require neither the download or transaction component, there is no need to deploy the Self-Service Module in the DMZ.

• a connection to the Entrust Notification Service, which is a Web service hosted by Entrust. This is an optional connection, and is only required if you are deploying Entrust IdentityGuard Mobile with transaction notifications (pop-up alerts).



• Web server in the DMZ. This Web server:

– must have Tomcat AJP connector installed and configured to connect to the AJP connector on the Self-Service ModuleOR

– must redirect requests on the standard HTTPS and HTTP ports to the Self-Service Module’s non-standard ports (8445 and 8081, respectively).

• a user with a browser and a soft token application (either Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Token).

• an administrator, to configure Self-Service and perform administration functions that are not available through Self-Service



Self-service - high availability architectureFor high-availability and failover reasons, you can deploy the Entrust IdentityGuard Self-Service Module on more than one hardware server and point each to a single Entrust IdentityGuard Server (Figure 53). You can also point your Self-Service Module to multiple Entrust IdentityGuard Servers (Figure 54 on page 210). Finally, you can deploy multiple Self-Service Modules and point them to multiple Entrust IdentityGuard Servers (not shown).

When installing the Self-Service Module on each machine, you are prompted for two URLs: the Entrust IdentityGuard Authentication URL and Administration service URL. If you have multiple Entrust IdentityGuard Servers as in Figure 54 on page 210, you can add additional Administration and Authentication URLs through the Self-Service Module’s Configuration interface.

Figure 53: High-availability Self-Service architecture



210

Figure 54: Multiple Entrust IdentityGuard Servers

As part of the Self-Service Module installation, you are asked for an internal Entrust IdentityGuard account that can be used to access the Entrust IdentityGuard Server. You should use different accounts for each Self-Service Module. Using the same account for all Self-Service Modules will result in errors when the account password is auto-renewed by one of the modules.



Federation Module architecturesAs part of the Entrust IdentityGuard product line, you can purchase the Entrust IdentityGuard Federation Module, which acts as a SAML IDP or OpenID OP. It enables Entrust IdentityGuard single-sign on authentication to SAML or OpenID enabled sites.

For more on the Federation Module, see “Entrust IdentityGuard Federation Module” on page 33.

The following are two example architectures:

• enterprise, see “Federation Module - enterprise architecture” on page 211

• SaaS with high-availability, see “Federation Module - SaaS with high availability architecture” on page 213

Federation Module - enterprise architectureThe following architecture shows how to deploy the Federation Module within your organization. In this scenario, there are several enterprise applications that require Entrust IdentityGuard authentication. You would configure these applications to redirect users to the Federation Module for authentication. (For this to work, the applications must be SAML or OpenID enabled.) The Federation Module then authenticates the user’s first- and second-factor credentials and redirects users back to the enterprise application, where they are logged in. Users can then access all the enterprise applications without having to resubmit their credentials.

Note: Because authentication is performed by the Federation Module, there is no need to integrate second-factor into the enterprise application itself using the Entrust IdentityGuard APIs. (An integration using the APIs would be mandatory if the Federation Module were not in the picture.)



212

Figure 55: Federation Module - enterprise architecture




IdentityGuard user accounts.

• Entrust IdentityGuard Server.

• Entrust IdentityGuard Federation Module, with the IDP or OP component installed.

• (Optional. Not shown.) Entrust IdentityGuard Self-Service Module, to deliver self-service functionality, such as the ability to reset a forgotten password.

• one or more SAML or OpenID-enabled enterprise applications. The Federation Module delivers multi-factor single sign-on to these applications.

• a user with a browser and a second-factor authenticator such as a hardware token or grid.

Federation Module - SaaS with high availability architectureThe following architecture shows how to deploy the Federation Module in an extranet scenario with fault-tolerance and high-availability. In this scenario, there are cloud (SaaS) services and partner sites outside your enterprise that you want to let users access. You would configure these external applications to redirect users to the Federation Module for authentication. (This redirection only works if the applications are SAML or OpenID enabled.) The Federation Module then authenticates the user’s first- and second-factor credentials and redirects users back to the cloud or partner site, where they are logged in.

Note: Because authentication is performed by the Federation Module, there is no need to integrate second-factor into the external application itself using the Entrust IdentityGuard APIs. (An integration using the APIs would be mandatory if the Federation Module were not in the picture.)

For high-availability and failover reasons, you can deploy the Federation Module on more than one hardware server and point each to one or more Entrust IdentityGuard Servers.

When installing the Federation Module, you are prompted for two URLs: the Entrust IdentityGuard Authentication URL and Administration service URL. If you have multiple Entrust IdentityGuard Servers as in Figure 54 on page 210, you can add additional Administration and Authentication URLs in the igfm.properties file.



214

Figure 56: Federation Module - SaaS with high availability architecture




IdentityGuard user accounts.

• multiple Entrust IdentityGuard Federation Module servers, with the IDP or OP component installed.

• a loadbalancer to distribute traffic across Federation Module servers.

• multiple Entrust IdentityGuard Servers. The Federation Modules are configured to failover to the next Entrust IdentityGuard Server when the primary one fails. This is a fault-tolerance configuration—there is no load-balancing.

• (Optional. Not shown.) One or more Entrust IdentityGuard Self-Service Module servers, to deliver self-service functionality, such as the ability to reset a forgotten password. When multiple Self-Service Modules are used, a loadbalancer must be placed in front of them.

• one or more SAML or OpenID-enabled SaaS applications or partner sites. The Federation Module delivers multi-factor single sign-on to these applications.

• a user with a browser and a second-factor authenticator such as a hardware token or grid. The user can be inside or outside your corporation’s boundary when they authenticate.



216

Enrollment Module architecturesAs part of the Entrust IdentityGuard product line, you can purchase the Entrust IdentityGuard Enrollment Module, which allows Entrust IdentityGuard administrators with the proper permissions to create new smart credentials and edit existing smart credentials. By default, the Smart Credential Enroller role includes the permissions required to create and edit smart credentials.

You can also use the Enrollment Module in a high-availability scenario with multiple Entrust IdentityGuard servers.

Figure 57: Enrollment Module architecture



• Entrust IdentityGuard Enrollment Module

• if capturing biometrics (such as photographs, fingerprints, or signatures), one or more third-party devices for capturing biometric information, such as a camera, fingerprint scanner, and signature scanner

• Entrust IdentityGuard Enrollment Module Fingerprints Package, if capturing fingerprint data



Note: You do not require the fingerprints package if you are not capturing fingerprint data.

You must install the fingerprints package on each Entrust IdentityGuard Enrollment Module machine.

• an administrator to create and manage smart credentials, and enroll users for smart credentials



218

Print Module architecturesAs part of the Entrust IdentityGuard product line, you can purchase the Entrust IdentityGuard Print Module, which allows Entrust IdentityGuard administrators with the Smart Credential Issuer role to print and encode smart credentials.

You can also use the Print Module in a high-availability scenario with multiple Entrust IdentityGuard servers.

Figure 58: Print Module architecture



• Entrust IdentityGuard Print Module

• Entrust Authority Security Manager

Required if issuing certificates to users. Security Manager is the Certification Authority (CA) software. The CA issues the certificates to end users. Entrust



IdentityGuard communicates with Security Manager to request certificates for users.

• Alpha Card software, if your smart credential form factor is smart cards and you plan on printing enrollment data to the smart cards

Note: You do not require Alpha Card software if you are not physically printing on the face of a smart card.

Alpha Card is a card design application that accesses the Entrust IdentityGuard user repository for each smart credential user, and prints their enrollment data that you incorporate into your card layout design.

You must install the Alpha Card software on each Entrust IdentityGuard Print Module machine.

• smart card printer, if your smart credential form factor is smart cards and you plan on printing enrollment data to a smart card

If you are not physically printing on the face of a smart card, you do not require a smart card printer.

• smart card reader, if your smart credential form factor is smart cards and you plan on encoding enrollment data to a smart card

If you are not encoding to a smart card, you do not require a smart card reader.

• an administrator to add the Print Module to Entrust IdentityGuard Server, and to print and encode smart credentials



220

Mobile enrollment architectureBelow is a typical architecture used with the mobile enrollment feature. (Do not confuse this with the Entrust IdentityGuard Mobile software product. Architectures for that are in “Self-service - soft token architecture” on page 207.)

Each component and actor is explained in detail following the diagram.

Note: LDAPS is not supported.

Figure 59: Mobile enrollment—basic architecture



Requirements• user with mobile device

The user initiates the digital ID enrollment by clicking the I’d like to request a digital ID link on the Self-Service site from within the mobile device.

Consult the Entrust IdentityGuard Server Release Notes for the latest supported

• Web server

As a best-practice, place a Web server in front of the Self-Service Module. You can use any brand and version of Web server. It will need to be configured to forward requests to the Self-Service Module. Instructions are provided later in this guide.

• Self-Service Module

You must use Entrust IdentityGuard Self-Service Module 10.0 with patch 167900 or later.


You must use Entrust IdentityGuard Server 10.0 with patch 168137 or later.

• Repository (for Entrust IdentityGuard)

You can use any repository supported by the version of Entrust IdentityGuard Server you are using, as long as it is separate from the Security Manager LDAP Directory. See the Entrust IdentityGuard Server Release Notes for supported repositories.

• Security Manager and Security Manager Administration

Security Manager is the CA software. You must use Entrust Authority Security Manager 7.1 SP3 or higher and a database supported by the software (not shown). To administer Security Manager, a user interface must be installed, such as Security Manager Administration or Administration Services (not shown).

• LDAP directory (for Security Manager)

You must use an LDAP-compliant directory that is supported by the version of Security Manager you are using. See the Entrust Authority Security Manager Release Notes for supported LDAP directories.

• Administrator

An administrator manages users, certificates, the Entrust IdentityGuard system, and the Security Manager system, through various user interfaces provided with the Entrust products.



222

C

Grid card usability study

Entrust IdentityGuard was introduced to the market in late 2004. Since inception, it has generated significant interest in the market due to its ability to cost-effectively combat identity theft (from phishing and pharming) as well as address enterprise desktop and remote access security needs.

In May 2005, Design Interpretive conducted an independent usability study on Entrust IdentityGuard grid authentication. The extremely positive results of the study validate how easy Entrust IdentityGuard grid authentication is to use for both consumer and enterprise application security.

This appendix contains the following sections:

• “Entrust IdentityGuard grid card usability study” on page 224

• “Recommendations” on page 227

• “Grid authentication implementation” on page 229

223

224

Entrust IdentityGuard grid card usability studyFor organizations that want a strong authentication solution that is easy to use and easy to deploy, the results of this study show that Entrust IdentityGuard grid authentication is an ideal candidate. Built and supported by security experts from Entrust, Entrust IdentityGuard delivers a highly secure way of strongly authenticating users, whether in a consumer situation that demands increased protection against identity theft, or an enterprise situation that is looking to strengthen security for applications like remote access or desktop authentication.


• “Usability test summary” on page 224

• “Objective” on page 224

• “Methodology” on page 225

• “Usability test results” on page 225

Usability test summary• 344 people participated in the study

• Usability of Entrust IdentityGuard grid authentication was excellent and received a very high accuracy rate for authentication.

There were no statistical performance differences across the grid card designs (varying sizes/layouts).

• The procedure required to successfully complete the Entrust IdentityGuard challenge is inherently simple and has high user acceptance.

– 100% of participants achieved unaided successful login in two attempts.– 93% of participants were somewhat or very willing to use it once per day.

• The temporary PIN login procedure for forgotten or lost grid cards was straightforward and well understood by users.

100% achieved unaided successful login in two attempts.

ObjectiveThe objective of the study was to assess the overall usability of Entrust IdentityGuard grid authentication in both consumer and enterprise deployment scenarios. In addition, the study looked to maximize the usability of Entrust IdentityGuard grid authentication by formally testing various design implementations of:

• the coordinates table

For example, the number of cells and the visual delineation of rows and columns.

• the login screen design and challenge process flow



For example, whether the challenge is consolidated into one screen or spread across two screens.

The objective of these formal tests was to provide recommendations based on testing, as well as gather user feedback on their experiences.

MethodologyThe test had two separate execution phases, focusing independently on a consumer environment through Web testing and an enterprise environment for desktop authentication. It should be noted, that although desktop authentication was tested only for enterprise users, the expectation is that similar excellent results would be achieved for using Entrust IdentityGuard grid authentication for remote access applications like IP/SEC or Enterprise methodology.

The enterprise test was conducted using a face-to-face interview technique. Desktop authentication with Entrust IdentityGuard grid cards was used as the method of understanding the usability in the enterprise, with the assumption that usability of Entrust IdentityGuard grid cards for remote access would be similar. The same Entrust IdentityGuard grid options that were used for the consumer testing were used for the enterprise testing.

Key details of the testing include:

• Seventeen people from a medium sized enterprise were tested in a focus group environment.

• An Entrust IdentityGuard temporary PIN was used as an alternative to an Entrust IdentityGuard challenge in order to assess usability in situations where a user has lost or forgotten their Entrust IdentityGuard grid card.

Usability test resultsThe results of the independent testing for Entrust IdentityGuard grid authentication were extremely positive for both the consumer and the enterprise.

Key findings of the enterprise study:

1 Usability of Entrust IdentityGuard grid authentication was excellent and a very high accuracy rate of grid number lookup was achieved.

Across the four different grid card designs and layouts (See Figure 60 on page 226), no statistical difference was found. This shows that organizations have the flexibility to deploy the grid size and layout that is best for them within the bounds of the recommendations found here (see “Recommendations” on page 227).

2 The procedure required to successfully complete the Entrust IdentityGuard challenge is inherently simple and has high user acceptance.

225Grid card usability studyReport any errors or omissions


226

Figure 60: Successful login attempts

Figure 3: Enterprise initial authentication attempts

2nd try29%

1st try71%

Figure 3: Enterprise initial authentication attempts

2nd try29%

1st try71%

• 100% of participants achieved unaided successful login in two attempts; 71% of users on the first attempt and the other 29% on the second attempt.

• 93% of participants were somewhat or very willing to use it once per day.

3 The temporary PIN login (for forgotten/lost grid cards) procedure was straightforward and well understood by users.

• 100% achieved unaided successful login in two attempts.



RecommendationsBased on the results of the study, the following recommendations should be considered when deploying Entrust IdentityGuard grid authentication to ensure a high degree of usability.


• “General guidelines” on page 227

• “Grid card design and layout” on page 227

General guidelinesYou can increase probability of initial successful grid challenge response if you:

• Provide first time users with written instructions that graphically depict how to use the grid card and login procedure.

• Provide access (using a corporate Intranet or training center) to instruction materials (such as a multimedia demonstration of how to use the grid for that particular application) describing how to use an Entrust IdentityGuard grid card.

Grid card design and layoutConsider the following recommendations for grid card design and layout.

FontsGiven that the different fonts used in the test did not affect usability, it is recommended that you choose the font within the following guidelines to ensure a high level of usability:

• Use fonts that people are generally familiar with (Arial, Verdana, Helvetica, and Times lend themselves to better readability).

At small sizes, Verdana offers bigger looking characters at the same point size as other fonts.

• Use a sufficient character point size to ensure readability. A minimum of 11-point is recommended.

Use of colorGiven that the different fonts used in the test did not affect usability, it is recommended that customers choose the font within the following guidelines to ensure a high level of usability:

• Avoid color combinations that create a tendency to “vibrate.”



228

• Assist users that may have some form of color blindness.

– Do not rely on color alone to convey information.– Avoid using only red and green in the grid design.– Maintain a high contrast between text and background.

Design of the grid Given that grid sizes tested here did not affect usability, it is recommended that you choose the grid size that is best suited to your security requirements (noting that increased grid size can deliver increased security) according to the following guidelines:

• Do not use more than seven rows or columns in the grid. Adding more rows or columns compromises size of text and readability.

• Do not use multiple characters within an individual grid cell as this tends to compromise the size of text and readability.

• Use table row and column highlighting.

Although it was not a factor in this study, tables with both row and column grid lines typically enable users to process data faster than tables with only row or only column highlighting.

• Format column and row titles with emphasis (bold or a background color) to assist in the immediate understanding of the table contents.

Titles should be sufficiently different than the data in the table to assist in distinguishing between the table data and the row and column titles with color or value.

• It is essential that all contents of the grid be precisely aligned and that each column appear to the eye to be in virtual alignment with neighboring elements.



Grid authentication implementationThis section provides more information on what the study determined about implementing grid authentication.


• “Web login challenge method” on page 229

• “Mutual authentication (through displaying a authentication secret)” on page 229

• “Temporary PIN length” on page 229

Web login challenge methodGiven that the type of login challenge method did not affect usability, it is recommended that organizations implement the method that is best suited to organizational security requirements. However, there are inherent security benefits to implementing a two-screen authentication process:

• A two-screen approach delivers the ability to achieve mutual authentication (as a way of addressing phishing).

• A two-screen approach delivers the ability to lock a challenge for a user until it is successfully completed (to limit the ability to brute-force attack a Web site by cycling through challenges).

Mutual authentication (through displaying a authentication secret)

If the Entrust IdentityGuard serial number (or another authentication secret like an image stored by Entrust IdentityGuard) is displayed on the login screen to achieve mutual authentication (used to help address phishing attacks), it is recommended that any documentation sent to the user reinforces the security implications of that authentication secret.

For more information, see “Mutual authentication methods” on page 64.

Temporary PIN lengthWhen using a temporary PIN (for instances where the user has forgotten or lost their grid and needs access to applications until a new grid is issued), it is recommended to use a PIN with five to nine characters, depending on your security requirements.

• Five elements is the minimum needed to ensure security.

• Nine elements is the typical upper span limit of human memory. Going beyond nine elements makes it very difficult for a user to remember.



230

Index

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z- -

IndexIndex

Aactivation of grid cards and tokens 165ActiveX for machine authentication 72Administration interface 92Administration service 32administrator 92alerts

see transaction notificationsalias 93alias in a consumer deployment 94Android 147anonymous grids 132application data 67application integration 102architecture

consumer 203evaluation 177Federation Module 211for VPN, OWA 205high availability 178overview 177self-service enterprise 205standard 177

audit database 90audit reporting 90authentication

benefits 25definition 25first-factor 48methods 49multiple factors 25overview of authentication methods 42single sign-on 33skip first-factor 48

authentication API 102authentication factor. See authentication methodsauthentication methods 41

comparison 44external 48grid 51, 121grid replay 64

image or message replay 65knowledge-based 58machine 67machine authentication 59mutual authentication 64one-time password (OTP) 60passcode list 56password 47Radius server 47smart credential 83temporary PIN 78token 49, 143transaction 49

authentication secret 105Authentication service 31automation 142

Bbackup and recovery 89baseline architectures 175BlackBerry 147Braille grid card 136branding

tokens 148

Cchallenge

grid 52, 126least-used cells 126lock out 97passcode list 56random 126size 125token 144

client application 38cloud services 211components 29

Entrust IdentityGuard Desktop 36ISAPI filter 38

231

232

B C D E F G H I J K L M N O P Q R S T U V W X Y Z- -A

Radius proxy 35Remote Access Plug-in 37repository 34server 30

computer identity 67confirmation

transaction 79, 145cookie for machine authentication 67Customer support 18

Ddatabase 109

for storing audits 90delivery of grid cards and tokens 165delivery of one-time passwords 60, 61deployment of Entrust IdentityGuard

overview 86planning 85

deployment, multinode 209desktop architecture

evaluation 198high availability 200standard 199

Desktop for Microsoft Windows 36directory repository 108

enroll users from directory 108map contact info from directory 108suspend expired and disabled LDAP users 108

disaster recovery 115DisplayCard Tokens 50distribution of grid cards and tokens 165

EeGrid

distribution 128distribution in Self-Service Module 128security 135

email, secure 141end user. See userend-to-end encryption 141enroll users from directory 108enrollment 162

from LDAP repository 163LDAP users 108

Entrust IdentityGuard Administration service 32Entrust IdentityGuard Desktop for Microsoft Windows 36

Entrust IdentityGuard ISAPI filter 38Entrust IdentityGuard Mobile 50, 79, 145

see also soft tokensEntrust IdentityGuard Radius proxy 35Entrust IdentityGuard Remote Access Plug-in 37Entrust IdentityGuard Self-Service Module 32Entrust IdentityGuard Server 30Entrust IdentityGuard Soft Token 42, 45, 50, 51, 144, 147,

148, 162, 172architecture 207see also soft token

Entrust tokens 49, 143evaluation architecture 177external authentication 48

Ffailover 115

advanced multi-site 119geographically-dispersed repositories 118local repository 117multi-site 118Radius server 120repository 117scenarios 115

Federation Module 33architecture 211

file transmission 141with end-to-end encryption 141with secure email 141with secure FTP 141with SSL 141

fingerprint, machine fingerprint 72firewallsfirst-factor authentication 25, 35, 48flash object for machine authentication 67FTP 141

GGetting help 18grid

automating 142cell entropy 123cell format 122challenge 52challenge algorithm 126challenge size 55, 125



deployment risks 55distribution 128format 122lifetime 55, 123location replay 64one-step authentication 52passcode list 56replacement 123sample passcode list 57serial number 64size 55, 122two-step authentication 53

grid authentication 51, 121grid card

Braille 136cost factors 139eGrid 135production 136production model 127security 135usability study 223

grid card productioncosts 139Entrust IdentityGuard Card Production Service 139in-house 136outsourced 137

Grid card production service 139grid card usability study 223

recommendations 227results 225summary 224

grid production model 128group 98

Hhigh availability

architecture 178failover scenarios 115

Iimage library on Entrust TrustedCare 66image replay, required disk space 66integrating applications 102

considerations 105Microsoft Windows 103VPN 103

Web 102wireless access portal 104

integrating UNIX or Linux server 37, 202inventory of grid cards and tokens 165iPhone 147ISAPI filter 38

JJ2ME 147JasperReports (see reports) 36Java Phone 147JavaScript for machine secrets 71

KKerberos 48knowledge-based authentication 58

challenge size 155exact answers 156question qualities 151question sources 150security 157selecting questions 153word map 155

LLDAP directory 108

enrolling users 108, 114suspending disabled and expired users 108suspending expired and disabled users 97updating contact information 108

least-used cells challenge 126life cycle 159

delivery and activation of grid cards and tokens 165enrollment 162maintenance 173overview 160renewal of authentication factors 168replacement of authentication factors 170usage stage 167

lock out, reset 167

Mmachine authentication 59, 67

233Index

234


application data 67cookie 67flash object 67machine fingerprint 67machine nonce 67machine secret 67machine tag 67sequence nonce 67with questions 149, 154

machine fingerprint 67application data 67Get 69Get request 73sources 69

machine nonce 67machine secret 67

using ActiveX 72using Javascript 71

machine tag 67machine nonce 67sequence nonce 67

maintenance 173man-in-the-browser 79map contact info from LDAP directory 108master user 91master user shell 91Microsoft Windows desktop user 39Microsoft Windows remote architecture


migrating to another platform 113migrating to Entrust IdentityGuard 114

Radius 114migration

from RSA 114mitb attack, see man-in-the-browsermobile user 40monitoring

SNMP 90multifactor authentication 25multinode deployment 209multi-site failover

advanced 119standard 118

mutual authentication 43, 64grid replay 64image library 66

image or message replay 65

Nnetwork diagram, see architecturenotification

transaction 79, 145notification service 79notifications

of transactions 79, 145

Oone-step grid authentication 52one-time password (OTP)

authentication 60delivery 60, 61

OOB, see out-of-bandOpenID 33operations 89organization authentication

See mutual authenticationOTP, see one-time passwordOutlook Web Access

architecture for 205out-of-band

authentication 60password delivery 60, 61

OWA, see Outlook Web Access

PPAM Plug-in 37, 202passcode list

authentication 56challenge 56deployment risks 58, 61length 57production 57sample 57scratch cards 57

password authentication 47people needed for deployment 88performance

repository 109testing 111

performance testing 111pharming 55



phishing 55physical security 90planning deployment of Entrust IdentityGuard 85Pluggable Authentication Module Plug-in 202Pluggable Module Plug-in 37Pocket Tokens 50policies 87preproduction model, grid cards 132produce-and-assign model 128producing grid cards 136production file

pre-production model 132transmitting 141

Professional Services 19

Qquestion and answer. See knowledge-based authentication

RRadius

migrating from 114Radius proxy 35, 47, 104Radius server

authentication 47failover 120

random challenge 126recovery 89remote access architecture


Remote Access Plug-in 37renewal of authentication factors 168replacement of authentication factors 170replay

grid values 64image 65message 65serial number 64

reports 36JasperReports 36PDF or CSV 36permissions 36

repository 34database 109, 117directory 108, 117

failover 34performance and maintainability 109selecting 108synchronization 174

repository failover 117geographically dispersed 118local 117

RRAS user 39RSA, migrating from 114

SSaaS 211SAML 33sample Web application 44scratch cards for passcode list 57search bases 100second-factor authentication 42secure email 141secure FTP 141Self-Service

about 203activating soft tokens through 147

Self-Service architectureconsumer 203enterprise 205soft token 207

Self-Service Module 32eGrid distribution 127, 128register questions and answers 153use in automation of processes 142use in migration to Entrust IdentityGuard 114user registration 162

sequence nonce 67shared secrets 106single sign-on 33, 211smart credential

authentication 83SNMP monitoring 90soft token

advantages 51downloading and activating 147see also Entrust IdentityGuard Mobile

soft token architecture 207soft tokens 144software as a service 211SSL

securing user responses 31

235Index

236


transmitting files 141SSO 211SSO, see single sign-onstandard architectures 177strong authentication 24suspend disabled/expired directory users 108system monitoring 90

TTAN. See passcode listTechnical Support 18technology 86temporary PIN

authentication 78length 229

testing performance 111token

assigning 146authentication 49, 143challenge-response mode 51deployment 146display card 50entering values 144lifetime and replacement 144pocket 50response-only mode 51security 148security and branding 148see also soft tokenusing multiple 144vendors 144

topology, see architecturetransaction

component 79, 145notifications 79, 145

transaction authentication 49Transaction notifications 79, 145troubleshooting 89two-step grid authentication 53typographic conventions 15

Uusability study, grid cards 223user 39

enrollment 108, 162groups 98

life cycle 159locking out 96Microsoft Windows 39mobile 40requirements 93RRAS 39services 95suspending 97training 94VPN 39Web 40

user enrollmentLDAP 114

user enrollment from LDAP repository 108, 163user ID 93, 94user self-administration

Self-Service Module 32user self-registration

Self-Service Module 32, 114

VVPN

architecture for 205VPN architecture


VPN user 39

WWeb architecture


Web services 31Web user 40Windows Mobile 147wireless access architecture

evaluation 187standard 188

wireless architecturehigh availability 189

word map for knowledge-based authentication 155


Documents

IG 100 Deploy Guide