IG 100 Deploy Guide

Entrust
IdentityGuard 10.0 Deployment Guide

Document issue: 1.0 Date of Issue: August 2011
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
TOC
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

Revision information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Documentation conventions Note and Attention text Related documentation Obtaining documentation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Documentation feedback Obtaining technical assistance Technical support
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Telephone numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Email address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Entrust Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
About Entrust IdentityGuard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21

Why use Entrust IdentityGuard? Issuing digital IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Issuing digital IDs to mobile devices . . . . . . . . . . . . . . . . . . . . . . 22 Issuing digital IDs to smart credentials . . . . . . . . . . . . . . . . . . . . 23 Issuing smart credentials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 . . . . . . . . . . . . . . . . . . . . . . . . . 24 . . . . . . . . . . . . . . . . . . . . . . 25 . . . . . . . . . . . . . . . . . . . . . . . . 25 Enabling multi-factor authentication Benefits of multifactor authentication
Challenges of first-factor authentication
Identities become difficult to steal . . . . . . . . . . . . . . . . . . . . . . . 25 Stolen identities become difficult to reuse . . . . . . . . . . . . . . . . . 25 Multifactor authentication choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 . . . . . . . . . . . . . . . . . . . . . . . . . . 26 . . . . . . . . . . . . . . . . . . . . . . . . 26 First-factor authentication choices Second-factor authentication choices Mutual authentication choices Machine authentication Risk-based authentication
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Entrust IdentityGuard components Entrust IdentityGuard server
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Entrust IdentityGuard Federation Module Entrust IdentityGuard Enrollment Module Entrust IdentityGuard Print Module Repository First-factor authentication application Entrust IdentityGuard Radius proxy Reports . . . . . . . . . . . . . . . . . . . . 32 . . . . . . . . . . . . . . . . . . . . . 33 . . . . . . . . . . . . . . . . . . . . 34
. . . . . . . . . . . . . . . . . . . . . . . . . 34 . . . . . . . . . . . . . . . . . . . . . . . 35 . . . . . . . . . . . . . . . . . . . . . . . . . 35 . . . . . . . . . . 36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 . . . . . . . . . . . . . . . . . . 37
Entrust IdentityGuard Desktop for Microsoft Windows Entrust IdentityGuard Remote Access Plug-in Entrust IdentityGuard PAM Plug-in Entrust IdentityGuard ISAPI filter Citrix XenApp integration package CA SiteMinder integration package Client applications
. . . . . . . . . . . . . . . . . . . . . . . . . 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 . . . . . . . . . . . . . . . . . . . . . . . . . . 38 . . . . . . . . . . . . . . . . . . . . . . . . . 38 . . . . . . . . . . 38
IBM Tivoli Access Manager (TAM) integration package Entrust IdentityGuard users
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
Document issue: 1.0
First-factor authentication methods Password authentication External authentication Radius server authentication
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 . . . . . . . . . . . . . . . . . . . . . . . 49
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Second-factor authentication methods Grid authentication Passcode lists
Token (and soft token) authentication
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Determining the grid challenge size . . . . . . . . . . . . . . . . . . . . . . 55 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 . . . . 60 Knowledge-based authentication
Out-of-band (OOB) one-time password (OTP) authentication Certificate authentication Mutual authentication methods Image and message replay Machine authentication
One-time password delivery systems. . . . . . . . . . . . . . . . . . . . . 61 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 . . . . . . . . . . . . . . . . . . . . 64 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 . . . . . . . . . . . . . . . . . . . . . . . . . 69
Grid serial number or grid location replay
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Computer registration process
Sources of machine fingerprint data
Basic Web browser without client-side software . . . . . . . . . . . . 69 Basic Web browser with client-side software . . . . . . . . . . . . . . . 72 Web application (server-side) . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Risk-based authentication Setting risk policies IP geolocation Certificates Blacklists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Setting authentication policies
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Temporary PIN authentication Transaction verification
Using personal verification numbers
Smart credential authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Planning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Planning: initial considerations People . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Entrust IdentityGuard policies Operations
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Backup and recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 System monitoring. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Other precautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Planning administrative tasks Assigning master users Assigning administrators Planning user requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Alias and user ID requirements Training users
Aliases in a consumer deployment . . . . . . . . . . . . . . . . . . . . . . . 94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Providing services to users Locking users out
Preventing brute force attacks through lockouts . . . . . . . . . . . . 96 Preventing phishing attacks through challenge timeouts . . . . . . 96 PIN-protection lockout. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Suspending users Group requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 . . . . . . . . . . . . . . . . . . . . . . . . . . 98 . . . . . . . . . . . . . . . . . . . . . . . . . 98 . . . . . . . . . . . . . . . . . . . . . . 99 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Groups in a consumer deployment Groups in an enterprise deployment Group implementation
Analyzing your companys group needs
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Document issue: 1.0
Deployment considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Application integration Web integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 . . . . . . . . . . . . . . . . . . . . . . . . . 104
Microsoft Windows integration VPN remote access integration Wireless Access Portal integration Self-Service integration Application considerations Using shared secrets Selecting a repository
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 . . . . . . . . . . . . . . . . . . . . . . . 107
Integrating with existing user management systems Using a Hardware Security Module (HSM) Directory repositories Database repositories
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 . . . . . . . . . . . . . . . . . . . . . . . . . . 109 . . . . . 113 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 . . . . . . . . . . . . . . . . . . . . . 114 . . . . . . . . . . . . . . . . . . . . . 114 . . . . 115
Performance and maintainability Performance testing strategies
Backing up, restoring, and migrating from one platform to another Switching users over to Entrust IdentityGuard Creating users in Entrust IdentityGuard High availability and disaster recovery Repository failover
. . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Entrust IdentityGuard Server hot-standby and load-balancing
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Local repository failover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Geographically-dispersed repository failover . . . . . . . . . . . . . . 118 Radius server failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Deploying grid authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

Grid requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Grid size and format
Grid size impact. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Grid format impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Grid lifetime and replacement Challenge requirements Challenge size . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Varying the grid challenge size . . . . . . . . . . . . . . . . . . . . . . . . . 125 Challenge algorithm Grid card production models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Produce-and-assign model
Entrust IdentityGuard Self-Service Module eGrids . . . . . . . . . . 128 Producing and assigning physical grid cards . . . . . . . . . . . . . . . 128 Preproduction model Grid security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Forcing grid card activation Physical grid card security eGrid security
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Physical grid card production options In-house grid card production
Typical characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Outsourced grid card production . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Typical characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Entrust IdentityGuard grid card production . . . . . . . . . . . . . . . . . . . 139 Typical characteristics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Grid card production cost factors Secure file transmission Secure email Secure FTP Secure Sockets Layer . . . . . . . . . . . . . . . . . . . . . . . . . . 139 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
End-to-end encryption Automating processes
Document issue: 1.0
Deploying token authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Using tokens for authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 . . . . . . . . . . . . . . . . . . . . . 144 . . . . . . . . . . . . . . . . . 145 Token lifetime and replacement Entering token response Token deployment
Allowing users to have multiple tokens
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Using soft tokens for transaction verification Deploying hardware tokens
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 Sources of questions
Creating good questions Selecting a set of questions Challenge requirements Challenge size Challenge accuracy
Sample questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Enrollment of users Enrolling users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 . . . . . . . . . . . . . . . . . . 163
Enrolling smart credential users Delivery and activation Use of authenticators
User enrollment from LDAP user repository
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Renewal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 . . . . . . . . . . . . . . . . . . . . . 173 . . . . . . . . . . . . . . . . . . . . . . 173 . . . . . . . . . . . . . . . . . . . 174 . . . . . . . . . . . . . . . 174 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 . . . . . . . . . . . . . . . . . . . . . . . . 173
Replacement of authenticators Maintenance
Remove canceled grid cards and tokens Remove canceled smart credentials Remove inactive grid cards and tokens Synchronize with the repository
Remove unassigned grid cards and tokens
. . . . . . . . . . . . . . . . . . . . . . . . . . . 174 . . . . . . . . . . . . . . . . . . . . . . 174
Update images used for mutual authentication Update personal verification numbers Update IP geographical data
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Entrust IdentityGuard baseline architectures . . . . . . . . . . . . . . . . . . . . . . . .175

Architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 . . . . . . . . . . . . . . . . . . . . . . . 179 . . . . . . . . . . . . . . . . . . . . . . . . 180 . . . . . . . . . . . . . . . . . . . 181 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Evaluation architecture Standard architecture Web access architectures
High availability architecture
Web access - evaluation architecture Web access - standard architecture
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 Web access - high availability architecture VPN remote access architectures Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 . . . . . . . . . . . . . . . . . 183 . . . . . . . . . . . . . . . . . . . 184 . . . . . . . . . . . . . 185 VPN remote access - evaluation architecture VPN remote access - standard architecture
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 VPN remote access - high availability architecture Wireless access architectures Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 . . . . . . . . . . . . . . . . . . . . 187 . . . . . . . . . . . . . . . . . . . . . . 188 Wireless access - evaluation architecture Wireless access - standard architecture
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
10
Document issue: 1.0
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Wireless access - high availability architecture Microsoft Windows remote access architectures . . . . . . . . . . . . . . . . 189 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 . . . . . . . . . . . . . . . . . . . 190 . . . . . 190 . . . . . . . 191 . 192 Microsoft Windows remote access - evaluation architecture Microsoft Windows remote access - standard architecture
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Microsoft Windows remote access - high availability architecture Generic remote access architectures Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 . . . . . . . . . . . . . . . 194 . . . . . . . . . . . . . . . . 195 . . . . . . . . . . . 196 Generic remote access - evaluation architecture Generic remote access - standard architecture
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 Generic remote access - high availability architecture Microsoft Windows desktop architectures Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 . . . . . . . . . . . . . . . . . . . . . . . . 198 . . . . . . . . . . 198 . . . . . . . . . . . 199 . . . . . . 200 . . . . . . . . 202 Microsoft Windows desktop - evaluation architecture Microsoft Windows desktop - standard architecture
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199 Microsoft Windows desktop - high availability architecture Pluggable Authentication Module (PAM) Plug-in architectures Self-Service architectures Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203 . . . . . . . . . . . . . . . . . . . . . . . 203 . . . . . . . . . . . . . . . . . . . . . . . . 205 Self-Service - consumer architecture Self-service - enterprise architecture
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 Federation Module architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 . . . . . . . . . . . . . . . . . . 211 . . . . . 213 Federation Module - enterprise architecture
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Federation Module - SaaS with high availability architecture
11
Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 Enrollment Module architectures Print Module architectures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220 Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 Mobile enrollment architecture Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Grid card usability study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223

Entrust IdentityGuard grid card usability study Usability test summary Objective Methodology Recommendations . . . . . . . . . . . . . . . . . . . . . 224 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Usability test results General guidelines
Grid card design and layout
Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Use of color . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Design of the grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 Grid authentication implementation Web login challenge method Temporary PIN length . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 229
Mutual authentication (through displaying a authentication secret)
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
12
Document issue: 1.0
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
Revision information
Table 1: Revisions in this document Document issue and date 1.0 August 2011 Section All sections Description First release of this guide.
14
Document issue: 1.0

Report any errors or omissions
Documentation conventions
Table 2 contains the typographic conventions that appear in this guide: Table 2: Typographic conventions Convention Bold text (other than headings) Italicized text Blue text Purpose Indicates graphical user interface elements and wizards Used for book or document titles Used for hyperlinks to other sections in the document Used for Web links Example Click Next.
Entrust IdentityGuard Server Administration Guide Entrust TruePass supports the use of many types of digital ID. For more information, visit our Web site at www.entrust.com.
Underlined blue text Courier type
Use the entrust-configuration.xml file Indicates installation paths, file names, to change certain options for Verification Server. Windows registry keys, commands, and text you must enter Indicates variables (text you must replace with your organizations correct values) Indicates optional parameters By default, the entrust.ini file is located in <install_path>/conf/security/entrust. ini. dsa passwd [-ldap]
Angle brackets <> Square brackets [courier type]
Note and Attention text

Throughout 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.
About this guide

15
Related documentation
Entrust 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
16
Document issue: 1.0

Obtaining documentation
Entrust 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 feedback
You 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 Entrusts 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. support@entrust.com
About this guide

17
Obtaining technical assistance

Entrust 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 support
Entrust 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 numbers
For 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 address
The email address for Customer Support is: support@entrust.com
18
Document issue: 1.0

Entrust Professional Services

The 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
About this guide

19
20
Document issue: 1.0

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
Why use Entrust IdentityGuard?

There are three main reasons to use Entrust IdentityGuard: to issue digital IDsIssuing digital IDs on page 22 to issue smart credentialsIssuing smart credentials on page 23 to enable multi-factor authenticationEnabling multi-factor authentication on page 24
Issuing digital IDs

A 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 CAs 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 devices

Entrust 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 Id 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 users 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.
22
Document issue: 1.0

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 credentials

Entrust 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 credentials

Smart 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 Entrusts 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 Id like to activate a smart credential so I can start using it link.

23
Smart credential authentication is discussed further in Smart credential authentication on page 83.
Enabling multi-factor authentication

As online fraud and compliance regulations become more prevalent, standard user name and password authentication no longer offers sufficient security for your organizations 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
User name and password authentication resource
User that requires multifactor authentication
Company VPN device Entrust IdentityGuard Server
Company firewall
Employee repository
24
Document issue: 1.0

Challenges of first-factor authentication

Authentication 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 alonewhich are easy to steal and easy to reuseare 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 authentication

Multifactor 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 steal

With 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 reuse

Your 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 users 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.

25
Multifactor authentication choices

Entrust 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 choices

You 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 choices

Entrust IdentityGuard provides several second-factor authentication methods, including: card (grid and passcode list) authentication token authentication soft token authentication
26
Document issue: 1.0

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 choices

Mutual 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 authentication
Entrust IdentityGuard allows you to verify a user by comparing current properties of the users 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 authentication
Entrust IdentityGuard allows you to determine situations where second-factor authentication is applied, based on a users 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:

27
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 users certificate.
See Risk-based authentication on page 74 for a detailed description of risk-based authentication.
28
Document issue: 1.0

Entrust IdentityGuard components

The 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
User
First-factor authentication application
Entrust IdentityGuard Server
Repository
Figure 3: Entrust IdentityGuard as the sole authentication system with the Self-Service Module

29
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 server

The 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 IdentityGuards 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.
30
Document issue: 1.0

Figure 4: Entrust IdentityGuard components

Master user shell
Application server
Reports Entrust IdentityGuard Self-Service Server Entrust IdentityGuard Administration interface and Properties editor
SOAP (with SSL)
Repository Directory
Administration service Database Web administration application Authentication service
HTML/ HTTPS
SOAP (SSL is optional )
SOAP SOAP (SSL is optional ) (SSL is optional )
Entrust IdentityGuard Desktop for Microsoft Windows
Client authentication application
Entrust IdentityGuard Radius proxy
PAM Plug-in
UNIX or Linux Server
Entrust IdentityGuard Authentication service

The 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.

31
Entrust IdentityGuard Administration service

The 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 interface
Administrators use the Web-based Administration interface to perform system and user administration operations that define how Entrust IdentityGuard will work in your organization.
Properties editor
Administrators use the Properties editor to set or review the properties that govern the behavior of Entrust IdentityGuard and its components.
Master user shell

The 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 Module

Self-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
32
Document issue: 1.0

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 companys 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 Module

The 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.

33
For more information about the Federation Module, see Federation Module architectures on page 211.
Entrust IdentityGuard Enrollment Module

The 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 Module

The 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.
Repository
Entrust 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 34
Entrust IdentityGuard 10.0 Deployment Guide Document issue: 1.0
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 proxy

The 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 IdentityGuardno 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.

35
Reports
Entrust 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 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 Windows Login Feature environment Microsoft Windows Server 2003, 2008, Windows Vista, Windows 7 the Entrust IdentityGuard Desktop for Microsoft Windows release notes for details Windows 2003 Feature description 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
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 organizations policies and practices. 36
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-in

The 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-in

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

37
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 filter

Entrust 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 package

Entrust 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 package

Entrust makes available a Custom Authentication Scheme (CAS) for use with SiteMinder. When the CAS is installed into SiteMinders 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 package

Entrust 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 applications
Client applications use the Authentication API and the Administration API to access Entrust IdentityGuards 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.
38
Document issue: 1.0

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 users

Entrust IdentityGuard users are divided into different categories, based on how they access your organizations resources. See Entrust IdentityGuard baseline architectures on page 175 for diagrams showing how Entrust IdentityGuard interacts with these users.
Microsoft Windows desktop users

Microsoft 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) users

RRAS 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 users
VPN 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

39
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 users
Web 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 users
Mobile 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 users

Depending on the applet encoded on the smart credential, smart credential users can authenticate to physical and/or logical resources.
40
Document issue: 1.0

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. This chapter contains the following sections: 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
Overview of available authentication methods

This 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 IdentityGuards 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
42
Document issue: 1.0

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 )
Image replay authentication (user selected image )
Grid location replay authentication (grid locations shown specific to user)
Message replay authentication (user entered message)
43
machine authentication In machine authentication, the users identity is verified based on various properties of the users 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 users geographic location the presence of a valid certificate Risk 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 Password Physical requirements for users None Renewal options1 Sample use
Based on time
Requiring first-factor authentication
44
Document issue: 1.0

Table 4: Comparison of available authentication methods (continued) Authentication method Token Physical requirements for users Token hardware Renewal options1 Sample use
When device is lost or battery dies (6 years or more)
Requiring strong second-factor authentication Requiring strong second-factor authentication
Soft token
Computer with Software update Entrust IdentityGuard Soft Token installed, or a mobile device with Entrust IdentityGuard Mobile installed Card eGrid Based on use or time
Grid
Requiring strong second-factor authentication Requiring infrequent authentication Grid, passcode list, or token is temporarily unavailable Registering users and/or machines One-time, highly sensitive operation
Passcode list Temporary PIN
Printed list None
Based on use or time Based on use or time
Knowledge-based One-time password delivered by an out-of-band mechanism
None None2
N/A One-time use only (usually) Optional automatic replacement
Machine (can be part N/A of risk-based authentication) IP geolocation (risk-based) Certificate N/A N/A
Based on each login, Users access site from length of time, or when personally-owned users change computers computers N/A Usually a time limit; issue a new certificate Users access site from a variety of locations Authentication with or without explicit user response Authentication with or without explicit user response
Smart credential
Smart card or USB Usually a time limit; token3 issue a new certificate
45
Table 4: Comparison of available authentication methods (continued) Authentication method Physical requirements for users Renewal options1 Sample use
Replay (organization) Card, if using grid N/A location or serial number replay
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.
46
Document issue: 1.0

First-factor authentication methods

You can use Entrust IdentityGuard to directly manage first-factor authentication; that is, to check if a users 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 organizations password requirements.
Radius server authentication

For 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.
47
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 authentication
The 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.
48
Document issue: 1.0

Second-factor authentication methods

Your 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) authentication

Using tokens, your users can authenticate using a dynamic password after completing first-factor authentication.
49
By default, Entrust IdentityGuard supports a number of different token formats that can be deployed alone or in combination, based on your organizations 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.
50
Document issue: 1.0

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 Considerations 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. 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. Web access Microsoft Windows remote access VPN remote access
Deployment types
Grid authentication
With 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.
51
2 3
Entrust IdentityGuard presents the user with a challenge based on the grid on their card, as illustrated in Figure 9. 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. 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 users 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.
52
Document issue: 1.0

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 users 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.
53
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.
54
Document issue: 1.0

Table 6: Grid authentication advantages and considerations (continued) 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. Web access Microsoft Windows remote access VPN remote access Microsoft Windows desktop 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.
Deployment types
Deployment risks and mitigation
Determining the grid challenge size

There 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
55
authentication scenario in your application. The application must present a number of coordinates between the minimum and maximum number of required coordinates.
Passcode lists
Passcode 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.
56
Document issue: 1.0

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 Considerations Single use of a password makes it impossible for attackers to reuse authentication data. You can create multiple passcodes at once, lowering overhead. 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. Web access
Deployment type
57
Table 7: Passcode list authentication advantages and considerations (continued) Deployment risks and mitigation 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.
Knowledge-based authentication
A 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.
58
Document issue: 1.0

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 users 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 Considerations There are no physical requirements for users (such as grid cards or tokens). You can leverage previous interactions between the user and your organization. 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. Web access VPN remote access User-generated question-and-answer sets are not always secure. 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. Users do not always enter secure answers to questions. 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).
Deployment type Deployment risks and mitigation
59
Out-of-band (OOB) one-time password (OTP) authentication

There are situations where you want to provide users with an authentication method that, for security reasons, must be outside of the users 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 users 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.
60
Document issue: 1.0

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. 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 users 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. Web access VPN remote access 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.
Considerations
Deployment type Deployment risks and mitigation
One-time password delivery systems

Entrust IdentityGuard, straight out of the box, can generate and deliver one-time passwords through email, SMS (text) message, or through automated voice calls
61
using Authentify. You can also develop your own out-of-band (OOB) delivery methods using Entrusts 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 authentication
There 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 userthe 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 users credentials by updating the certificates, or cancel a users access by revoking a certificate or by making it inactive.
62
Document issue: 1.0

Table 10: Certificate authentication advantages and considerations (continued) 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. Web access VPN remote access
Deployment type
63
Mutual authentication methods

Your organization needs to have confidence in the users 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 2 3 4 5 The user completes first-factor authentication successfully. Entrust IdentityGuard presents the user with an authentication challenge. The challenge presents an image or information to the user that only the valid site could have. The user recognizes the image or information, and responds to the challenge. 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 replay

Grid 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 grids 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.
64
Document issue: 1.0

Table 11: Grid serial number and location replay authentication advantages and considerations (continued) 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. Web access Microsoft Windows remote access VPN remote access Microsoft Windows desktop
Deployment types
Image and message replay

Another 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
65
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 Considerations Allows a user to determine the sites legitimacy. Not dependent on a specific authentication method. 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). Web access
Deployment type
66
Document issue: 1.0

Machine authentication
Machine authentication provides validation of a users 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 users Web browser. A machine tag includes at least one of the following. machine nonce This is an arbitrary number generated only during machine registration. sequence nonce This 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 users 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
67
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 process

The 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 2 3 4 The application retrieves the machine tag and regenerates the machine fingerprint. Entrust IdentityGuard compares the machine tag and machine fingerprint to the machine secret stored in the repository. If the machine tag and machine fingerprint match the machine secret, Entrust IdentityGuard authenticates the user. The application changes the sequence nonce and Entrust IdentityGuard stores an updated version of the machine secret in the repository.
Entrust IdentityGuards machine authentication provides protection for users even if they have had other authentication data stolen by attackers. Because it is unlikely that
68
Document issue: 1.0

an attacker would enter the stolen credentials from the users computer, the machine authentication fails and the attacker cannot obtain access.
Sources of machine fingerprint data

There 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 software

This requires a Web browser only. From the users 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 users 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 browsers request to the server. Unfortunately, all data returned is quite predictable, even to an attacker who has never seen a particular browsers 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 applications 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.
69
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 navigator.appCodeName navigator.appName navigator.appMinorVersion navigator.cpuClass navigator.platform navigator.systemLanguage navigator.userLanguage navigator.appVersion Value Mozilla Microsoft Internet Explorer ;SP2; x86 Win32 en-us en-us 4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) true true 1170 1600 0 32 96 96
navigator.userAgent
navigator.onLine navigator.cookieEnabled screen.availHeight screen.availWidth screen.bufferDepth screen.colorDepth screen.deviceXDPI screen.deviceYDPI
screen.fontSmoothingEnabled true screen.height screen.logicalXDPI screen.logicalYDPI screen.updateInterval 1200 96 96 0
70
Document issue: 1.0

Table 13: General properties (continued) Property screen.width Value 1600
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. Table 14: MIME properties (partial list) Property navigator.mimeTypes[0].description navigator.mimeTypes[0].suffixes navigator.mimeTypes[0].type navigator.mimeTypes[1].description navigator.mimeTypes[1].enabledPlugin. filename Value Mozilla Default Plug-in * * Java NPOJI610.dll
Table 15: Plug-in information (partial list) Property navigator.plugins[0].description navigator.plugins[0].filename navigator.plugins[0].length navigator.plugins[0].name navigator.plugins[1].description Value Default Plug-in npnul32.dll 1 Mozilla Default Plug-in 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
71
browser platform (users operating system) screen size of users computer (height and width) screen color depth
Basic Web browser with client-side software

You 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 users 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/ht ml;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
72
Document issue: 1.0

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 users 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 Considerations It provides users with a seamless login experience. 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. Deployment type Web access
73
Risk-based authentication
There 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 policies

You can set two risk assessment policiesnormal and enhancedin Entrust IdentityGuard that determine how your application reacts in the five risk scenarios below: 1 2 A user logs in from a different computer than usual and machine authentication fails. For more information, see Machine authentication on page 67. A user logs in from an IP address that is not in the users location history list (IP addresses the user authenticated from recently). For more information, see IP geolocation on page 75. 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 A user logs in from an IP address that is on the IP blacklist. For more information, see Blacklists on page 76. A user logs in from a country that is on the country blacklist. For more information, see Blacklists on page 76. A user logs in with a certificate that is invalid. For more information, see Certificates on page 75.
4 5 6
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 policies

For 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 2 3 4 5 If one of machine authentication, certificate authentication, or IP authentication pass, automatically authenticate the user. If just IP authentication passes, automatically authenticate the user. If just machine authentication passes, automatically authenticate the user. If just certificate authentication passes, automatically authenticate the user. If both IP authentication and machine authentication pass, automatically authenticate the user.
Document issue: 1.0
74
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-andanswer) and one-time password.
IP geolocation
Entrust 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.
Certificates
Entrust 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.
75
Blacklists
Through 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 Considerations 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. 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 basisat 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.
76
Document issue: 1.0

Table 17: Risk-based authentication advantages and considerations (continued) Deployment type Web access
77
Temporary PIN authentication

In 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 Considerations It allows users to log in even if they have forgotten or lost their grid card or token. 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. Web access
Deployment type
78
Document issue: 1.0

Transaction verification
Transaction 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 sitea 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 notificationsthese 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 historya 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 2 A user performs a high-risk online transaction such as a large transfer of money from one account to another. The transaction is high-risk, so the transaction details are sent to the users 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. 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.
79
4 5
If the user selects OK to confirm the transaction, then a confirmation code is generated and displayed by the Entrust IdentityGuard Mobile application. 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.
80
Document issue: 1.0

Figure 19: Transaction verification with a notification
81
Using personal verification numbers

For 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.
82
Document issue: 1.0

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. Entrusts multipurpose smart credentials help provide true physical and logical access convergence. For additional flexibility, smart cards may be combined with an additional authentication mechanismsuch as grid authentication or digital certificatesthat 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
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 certificatesthat 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 users credentials by updating the certificates, or cancel a users access by revoking a certificate or by making it inactive. 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. Microsoft Windows desktop
Considerations
Deployment type
84
IdentityGuard 10.0 Deployment Guide
Document issue: 1.0

Planning your deployment

This chapter discusses items to address prior to, or during, the deployment of Entrust IdentityGuard. This chapter contains the following sections: Planning: initial considerations on page 86 Planning administrative tasks on page 91 Planning user requirements on page 93 Group requirements on page 98
85
Planning: initial considerations

This 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.
86
Document issue: 1.0

This section contains the following topics: Entrust IdentityGuard policies on page 87 People on page 88 Operations on page 89
Entrust IdentityGuard policies

Organizations 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). 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.
Organizations should:

87
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.
People
As with any system, Entrust IdentityGuards 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 Act as a single point of contact for the project and have the authority (recommended) to secure additional resources. Technical lead Bring knowledge of the organizations technical environment to the project. Throughout deployment (along with other personnel), obtain the necessary knowledge to support the production implementation into the operational phase. Administrate the directory if integrating with an LDAP-compliant directory. Administrate the database if integrating with a JDBC-compliant database or if using a database to store Entrust IdentityGuard audit information. Provide support during the planning and installation phases.
Directory administrator Database administrator
Network and systems administrators
Application Provide support for the application integration. development personnel Operations personnel Customer Support and Help Desk personnel Hardware procurement personnel Provide support for the operational requirements after deployment. Integrate support services for Entrust IdentityGuard into the existing support mechanisms. Obtain any necessary hardware (such as servers, grid cards, and tokens).
88
Document issue: 1.0

Table 20: People required for the deployment and operation of Entrust IdentityGuard Person or people System support personnel Job description Carry some of the responsibility for the ongoing support of Entrust IdentityGuard. Note: These people may be representatives from other groups in your organization.
Operations
Operation 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 recovery

Update 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 platformUNIX 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 organizations existing standards for data backup. Update your organizations 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.

89
System monitoring
Entrust 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 precautions
Locate 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 organizations approach to deploying applications into production, additional implementations of Entrust IdentityGuard into test or staging environments may be required.
90
Document issue: 1.0

Planning administrative tasks

Besides 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. This section contains the following topics: Assigning master users on page 91 Assigning administrators on page 92
Assigning master users

Assign 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 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
Consider the following when assigning the three master user roles:

91
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 administrators
Administer 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 theyve 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.
92
Document issue: 1.0

Planning user requirements

Users 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
This section contains the following topics:
Alias and user ID requirements

Users 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 users 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.

93
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 deployment

Related 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 banks 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 users
When deploying Entrust IdentityGuard, you must train your users to use the new authentication methods and have them register as required. Also, if you have
94
Document issue: 1.0

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 companys 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 users

An 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 users 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

95
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 out

Entrust 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 lockouts

To 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 timeouts

As 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 96
having a lifetime, the attacker has very little time to phish for the answer before the challenge expires.
PIN-protection lockout
Aside 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 users
Administrators 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 measurean 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.

97
Group requirements
Entrust 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 groups 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. This section contains the following topics: Groups in a consumer deployment on page 98 Groups in an enterprise deployment on page 98 Analyzing your companys group needs on page 99 Group implementation on page 100
Groups in a consumer deployment

There 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 users 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 deployment

There are many ways groups apply to users in enterprise environments: 98 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
Document issue: 1.0
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 companys group needs

Create 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 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?
What types of users do you have that require multifactor authentication?

99
Table 21: Things to consider when creating Entrust IdentityGuard groups (continued) Considerations How will you administer these groups? Comments 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?
Group implementation
Entrust 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.
100
Document issue: 1.0

Deployment considerations
This chapter provides information you should consider when deploying Entrust IdentityGuard in your organization. This chapter contains the following sections: 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
Application integration
You 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. This section contains the following topics: 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 integration
The 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.
102
Document issue: 1.0

Figure 21: Web integration using Authentication API
Microsoft Windows integration

Entrust 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 integration

Entrust 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
103
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 integration

Entrust 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 integration
The 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.
104
Document issue: 1.0

Application considerations
Define 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 users 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 systems

If 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.
105
For more information about implementing the Entrust IdentityGuard Administration API, see the Entrust IdentityGuard Programming Guide.
Using shared secrets

Entrust 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).
106
Document issue: 1.0

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 Serveryou cannot add an HSM after the product is already deployed. Note: Although other keys are used in the Entrust IdentityGuard systemto secure SSL communications, for examplethe HSM feature only applies to master keys.
107
Selecting a repository
Entrust 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 repositories
User 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
Document issue: 1.0
108
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 repositories
For 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 maintainability

The 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
109
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.
110
Document issue: 1.0

Performance testing strategies

You 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 2 Create test users. 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 2 3 4 Load the grid cells, one-time passwords, or tokens into an array. Capture the start time for a transaction. Send a request to the Entrust IdentityGuard Server requesting a challenge. If you are using grids: a b c 5 6 7 8 Receive the challenge and parse it for the requested coordinates on the grid. Look up the correct values for the response in the grid cells. Optional. Pause for think time to simulate a person providing the response to the challenge.
Send a request to the Entrust IdentityGuard Server with the values of the grid, token, or one-time passwords. Receive the response back from the server. Capture the time that the transaction is completed and calculate the elapsed time since the request. Report the elapsed time of the request to the screen, printer or file, as required.
111
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.
112
Document issue: 1.0

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 2 3 4 Backup your system configuration using the existing backup mechanism. Copy the backup file to the new platform. Install Entrust IdentityGuard on the new platform and, as part of the configuration steps, select to restore the configuration from a backup file. 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.
113
Switching users over to Entrust IdentityGuard

During 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 IdentityGuard

As 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.
114
Document issue: 1.0

High availability and disaster recovery

Entrust 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-balancing

You 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.
115
Figure 22: Hot-standby scenario
Figure 23: Load-balanced scenario
116
Document issue: 1.0

Repository failover
You 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 URLseither LDAP-compliant directories or databasesin 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 failover

In 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
117
Geographically-dispersed repository failover

This 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
118
Document issue: 1.0

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
119
Radius server failover

Configure 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 serverand Radius server failover is configuredEntrust 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
120
Document issue: 1.0

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. This chapter contains the following sections: 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
Grid requirements
This section focuses on the items you need to consider before determining what type of grid best suits your security needs and your users. This section contains the following topics: Grid size and format on page 122 Grid lifetime and replacement on page 123
Grid size and format

You can configure the size (the number of cells) and format (the contents of cells) of a grid according to your organizations 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 sizethe number of cells presented to the user at authentication.)
Grid size impact

The more cells in a grid, the better the resistance to an attacker who has gained some knowledge of a users 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 impact

Cell 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.
122
Document issue: 1.0

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 Rows and columns in grid Characters in grid Characters per cell Characters that can replace other characters Recommendations Maximize the number of rows and columns within physical form and usability constraints. Use single alphanumeric characters. Use one character per cell for maximum usability. 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 replacement

Grids 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 grids 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.

123
Table 23: Policy considerations associated with grid lifetime and replacement Policy consideration Lifetime based on time or usage? Recommendations Lifetime of card if based on time 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. Given the short window of opportunity for specific attacks, a life span of one year or more is recommended. 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.
Replacement and warning thresholds
124
Document issue: 1.0

Challenge requirements
This section focuses on the factors to consider before determining what type of grid challenge best suits your security needs and your users. This section contains the following topics: Challenge size on page 125 Challenge algorithm on page 126
Challenge size
You 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 attackers 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 size

Through 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.

125
Challenge algorithm
Entrust 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 users 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).
126
Document issue: 1.0

Grid card production models

At 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
Produce -and-assign model 1 . User exists in primary application 2. User created in Entrust IdentityGuard 3. Grid generated for user 4 . Card produced
Preproduction model 1 . Grid generated 2. Card produced 3. User exists in primary application 4 . User created in Entrust IdentityGuard 5 . Grid assigned to user

127
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. This section contains the following topics: Produce-and-assign model on page 128 Preproduction model on page 132
Produce-and-assign model
In 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 eGrids

The 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 necessarythe eGrids are automatically produced and delivered with no administrator action required.
Producing and assigning physical grid cards

The 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
128
Document issue: 1.0

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)
Optional steps required if user delivery information is not in Entrust IdentityGuard Repository .
1 . Entrust IdentityGuard Repository
6. Other repository
7 . Extract user information into second file
2 . Extract list of users
8 . Merge two files to create production file
9. Review and deal with errors
3 . Generate grids
4. Export production file
5. Securely transmit file to card producer
1 2 3
Ensure the users already exist in the Entrust IdentityGuard repository. Extract a list of the users from the repository who are to receive grid cards. 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. Export the selected users grids, user IDs, and delivery information into an Entrust IdentityGuard production file. 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.
4 5
6 7
(Optional) Based on the list of user IDs exported, access other corporate repositories to obtain the name and mailing information of the selected users. (Optional) Export the user information into a second file.

129
8 9
(Optional) Merge the two files together to create the Entrust IdentityGuard production file containing the user information and associated grid information. 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
1 . Entrust IdentityGuard Repository
2b . User logs in and requests card
3. Generate grids
2c . Cards requested in bulk
4 . Export production file
5 . Securely transmit file to card producer
1 2
Ensure the user exists in the primary applications repository. This repository also serves as the Entrust IdentityGuard repository. 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.
130
Document issue: 1.0

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. 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 4 Entrust IdentityGuard generates and assigns a grid to each user name. 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.
Complete the enrollment process with Maintenance on page 173.

131
Preproduction model
In 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
1 . Generate grids and store in repository
2. Export production file
3. Securely transmit file to card producer
4. Card creation and delivery
5. Entrust IdentityGuard Repository
6. Create user, select card, assign grid
132
Document issue: 1.0

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. 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 6 If you use an LDAP-compliant directory as the Entrust IdentityGuard repository, ensure the user entry exists in the directory. 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 cards 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

133
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 activation

When 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.
134
Document issue: 1.0

Grid security
Entrust 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 users last successful login time and date. If this information does not match the users 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 security

The 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 security
Using 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.

135
Physical grid card production options

You 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 production

Use 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 characteristics
The 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
Setup
The 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).
136
Document issue: 1.0

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)
Process
The 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. Analyze the Entrust IdentityGuard production file and select the appropriate card or paper stock for printing. Produce the Entrust IdentityGuard grid cards. 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 companys internal mailing information. 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.
2 3 4
Outsourced grid card production

For 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.

137
The 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.
Setup
The 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.
Process
The following steps are involved in outsourcing Entrust IdentityGuard grid card production. To outsource grid card production 1 2 3 4 5 6 Securely send the Entrust IdentityGuard production file to the grid card production facility in either an encrypted file format or a secure FTP arrangement. Analyze the production file and select the appropriate card or paper stock for printing. Analyze the production file for personalization information to be printed on the individual Entrust IdentityGuard grid cards. Analyze the production file for grid card shipping instructions. Produce the grid cards and insert them into addressed envelopes for distribution. 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).
138
Document issue: 1.0

The user follows the activation instructions contained in the grid card mailing.
Entrust IdentityGuard grid card production

For 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.
The 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)
Setup
Before 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 factors

There 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 Grid Card volume Branding detail (logos, colors) The cost increases as the card thickness increases. Removable scratch covers increase cost. Higher volumes cost less per grid card. More colors and complex graphics increase costs.

139
Table 24: Factors that influence the cost of grid card production (continued) Personalization detail Distribution requirements 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. 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.
140
Document issue: 1.0

Secure file transmission

Ensure 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 Layer

The 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 email
You 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 FTP
You 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 encryption
An 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).

141
Automating processes
To 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 users 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).
142
Document issue: 1.0

Deploying token authentication

This chapter provides deployment information for token and soft token authentication. This chapter contains the following sections: 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
Using tokens for authentication

Users 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 replacement

If 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 tokens

If 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 response

The users 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. 144
In addition to a tokens 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 users 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 verification

Transaction 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 sitea money transfer, for example. Users are then asked to confirm the transaction. For details, see Transaction verification on page 79.

145
Token deployment
Hardware tokens and soft tokens are deployed differently. Deploying hardware tokens on page 146 Deploying soft tokens on page 147
Deploying hardware tokens

Hardware 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 tokens
A 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 activation

When 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.
146
Document issue: 1.0

Deploying soft tokens

To deploy soft tokens, they must be installed and activated.
Installing the soft token

A user must install the soft token applicationeither Entrust IdentityGuard Mobile or Entrust IdentityGuard Soft Tokenon 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 devices 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 token

After downloading and installing the soft token application, users activate their soft token themselves, through Entrust IdentityGuards 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 users 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.

147
Token security
Entrust 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 users last successful login time and date. If this information does not match the users 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.
148
Document issue: 1.0

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 users normal login location and reserve the questions for when the user logs in from a different machine. This chapter contains the following sections: 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
Question requirements
This section provides you with information about how to create and select a set of questions for your users to answer. This section contains the following topics: Sources of questions on page 150 Creating good questions on page 151 Selecting a set of questions on page 153
Sources of questions
There 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 Generated codes Considerations Transaction data 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 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. 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.
Prepopulated lists
150
Document issue: 1.0

Table 25: Methods for generating knowledge-based questions (continued) Method User-generated Considerations 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.
Creating good questions

The 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. Table 26: Knowledge-based authentication criteria Criteria Privacy Considerations 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. 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.
Security

151
Table 26: Knowledge-based authentication criteria (continued) Criteria Usability Considerations Knowledge-based authentication must be simple and easy for users to use. The questions should have a wide applicability to the organizations 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 users 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.
Sample questions
The following are some examples of good questions: What is your spouses middle name? What is your favorite restaurant? What is your best friends first name? Who is your favorite fictional character? What is the middle name of your oldest sibling? What is your oldest siblings nickname? What is your maternal grandmothers middle name? What is your oldest childs middle name? What is your youngest childs nickname? Which sports team did you like most as a child?
What is the first name of your oldest nephew? What is your paternal grandmothers first name? What is your paternal grandfathers 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 spouses 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 What is your paternal grandfathers middle wedding? name?
152
Document issue: 1.0

What is the first name of your oldest child? What was the first name of your nearest neighbor in 2000? What was the name of your first roommate? What is the middle name of your oldest sibling? What was your favorite college or university year?
What is your youngest siblings nickname? What is the first name of your spouses oldest sibling? What is your mother-in-laws first name? As a child, what did you want to be when you grew up? What is your maternal grandfathers first name?
What is the first name of the person you went What is your dream job? to your prom with? What is the first name of your best childhood friend? What is the first name of your oldest niece? What is the first name of your mothers youngest sibling? What is your favorite pizza place? What is your maternal grandmothers first name? What was the make of your first car? What was the best holiday gift that you ever received? What street did you live on when you were 10 years old? What is the first name of your youngest child? How old was your father when you were born? (spell out the number) What is your mothers middle name? What is the first name of the youngest of your siblings? What is your spouses middle name? 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 siblings nickname? What is your fathers middle name? What is your favorite fruit? What is your favorite charity? Where did you meet your spouse for the first time? (Enter location only) What is your favorite vegetable? What was your grandfathers nickname? What is your favorite fragrance? What is your favorite hobby? What is the first name of your fathers youngest sibling?
Selecting a set of questions

A 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.

153
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 systems resistance to attack by making it more difficult for an attacker to anticipate a given users 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 users normal login location and reserve the questions for when the user logs in from a different machine.
154
Document issue: 1.0

Challenge requirements
This section focuses on the items to consider before determining what type of knowledge-based challenge best suits your security needs and your users.
Challenge size
You 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 accuracy
Once you have determined how many questions a user must answer to authenticate, you must determine how accurate a users answers must be.
Setting how many correct answers are required

Entrust 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 answers

By 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).

155
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
156
Document issue: 1.0

Security considerations
Entrust 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 users last successful login time and date. If this information does not match the users 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.

157
158
Document issue: 1.0

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
Life cycle management overview

This 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 PVNs Users 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
160
Document issue: 1.0

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.

161
Enrollment of users
Enrollment 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 users
During 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.
162
Document issue: 1.0

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 users

During 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 repository

If 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.

163
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 recordsthose 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.
164
Document issue: 1.0

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 users 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 persons identity
165
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).
166
Document issue: 1.0

Use of authenticators
During 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 users account.

167
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 users 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. 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.
168
Document issue: 1.0

For knowledge-based information or image/graphic replay authentication, an application requests new information from a user when they log in.
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.
If you are using grid cards, passcode lists, or tokens, complete the renewal process with Maintenance on page 173.

169
Replacement of authenticators
Entrust 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 users 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).
170
Document issue: 1.0

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.
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. 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
Determine whether you need to replace or recover the authentication data.

171
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 users 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.
172
Document issue: 1.0

Maintenance
Maintenance 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 tokens

Grid 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 credentials

Smart 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 credentialssuch as smart cards with employees names and picturesyou 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 tokens

Organizations 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.

173
Remove unassigned grid cards and tokens

Tokens 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 repository

Coordinate 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 authentication

You 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 numbers

Each 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 data

You can download new IP lists from Entrust. See the Entrust IdentityGuard Server Administration Guide for more information about updating IP data files.
174
Document issue: 1.0

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
Enrollment Module architectures on page 216 Print Module architectures on page 218 Mobile enrollment architecture on page 220
176
Document issue: 1.0

Architecture overview
There are three levels of baseline architecture in this section: evaluation, standard and high availability.
Evaluation architecture
Evaluation-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 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
Assumptions:
Standard architecture
Standard-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 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
Assumptions:

177
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 architecture

High 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 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
Assumptions:
178
Document issue: 1.0

Web access architectures

You 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 architecture

Figure 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

179
Web access - standard architecture

The 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 Entrust IdentityGuard Server 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
180
Document issue: 1.0

Web server located in DMZ that relays information between the client, the application server, and Entrust IdentityGuard Server client with Web browser an administrator to manage Entrust IdentityGuard users
Web access - high availability architecture

The 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

181
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 client with Web browser administrators to manage Entrust IdentityGuard users
182
Document issue: 1.0

VPN remote access architectures

You 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 architecture

Use 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

183
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 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 architecture

The 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
184
Document issue: 1.0

Requirements
directory and/or database on a dedicated server for the user repository Entrust IdentityGuard Server 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 an administrator to manage Entrust IdentityGuard users
VPN remote access - high availability architecture

The 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.

185
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 Servers load-balancers to divide the load among the various Entrust IdentityGuard Servers 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
186
Document issue: 1.0

Wireless access architectures

This 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 architecture

Use this architecture to evaluate how Entrust IdentityGuard can provide multifactor authentication for wireless users. Figure 41: Wireless access evaluation architecture
Wireless access point LDAP or database repository
EAP supplicant
Entrust IdentityGuard Server with Radius proxy
Requirements
wireless access point LDAP directory or database user repository

187
Entrust IdentityGuard Server and the Radius proxy
Wireless access - standard architecture

The 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
Distributed LDAP or database repository
EAP supplicant
Access server supporting RAS and EAP
Administrator
Requirements
wireless access point distributed LDAP directory or database user repository Entrust IdentityGuard Server and the Radius proxy an administrator to manage Entrust IdentityGuard users
188
Document issue: 1.0

Wireless access - high availability architecture

The 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
Firewall
Distributed LDAP or database repository Entrust IdentityGuard Server with Radius proxy
EAP supplicant
Wireless access point
Load -balancing cluster Entrust IdentityGuard Server with Radius proxy
Administrator
Requirements
wireless access point replicated and distributed LDAP directory or database user repository multiple Entrust IdentityGuard Servers with the Radius proxy an administrator to manage Entrust IdentityGuard users

189
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 architecture

Use 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) Entrust IdentityGuard Server
190
Document issue: 1.0

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 architecture

The 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
Firewall
Firewall
Distributed domain with Active Directory
Microsoft Remote Access Client
Microsoft RRAS with Entrust IdentityGuard Remote Access Plug-in
Administrator
Requirements
distributed domain configuration with user repository Entrust IdentityGuard Server
191
Microsoft Routing and Remote Access Service (RRAS) with Internet Authentication Service (IAS) Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on the IAS computer client with Microsoft Remote Access capabilities hard and soft firewalls creating a DMZ (demilitarized zone) for the RRAS, and protecting internal resources an administrator to manage Entrust IdentityGuard users
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.
192
Document issue: 1.0

Figure 46: Microsoft Windows remote access high availability architecture
Requirements
distributed domain configuration with replicated user repository Entrust IdentityGuard Servers load-balancers to divide the load between the Entrust IdentityGuard Servers Microsoft Routing and Remote Access Service (RRAS) with Internet Authentication Service (IAS) Entrust IdentityGuard Remote Access Plug-in for Microsoft Windows Server installed on the IAS computer client with Microsoft Remote Access capabilities hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote Access Server, and protecting internal resources an administrator to manage Entrust IdentityGuard users

193
Generic remote access architectures

This 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 architecture

Use this architecture to evaluate how Entrust IdentityGuard can provide multifactor authentication for remote users. Figure 47: Generic remote access evaluation architecture
Access server supporting RAS and EAP LDAP or database repository
Windows EAP client
Requirements
an LDAP directory or database user repository Entrust IdentityGuard Server and the Radius proxy access server supporting Remote Access Service (RAS) and EAP
194
Document issue: 1.0

remote Microsoft Windows client supporting EAP
Generic remote access - standard architecture

The 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 Entrust IdentityGuard Server and the Radius proxy access server supporting Remote Access Service (RAS) and EAP remote Microsoft Windows client supporting EAP hard and soft firewalls creating a DMZ (demilitarized zone) for the RAS, and protecting internal resources

195
an administrator to manage Entrust IdentityGuard users
Generic remote access - high availability architecture

The 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
Firewall Firewall
Distributed LDAP or database repository Entrust IdentityGuard Server with Radius proxy
Windows EAP client
Access server supporting RAS and EAP
Load -balancing cluster Entrust IdentityGuard Server with Radius proxy
Administrator
Requirements
replicated and distributed LDAP directory or database user repository multiple Entrust IdentityGuard Servers with the Radius proxy access server supporting Remote Access Service (RAS) and EAP remote Microsoft Windows client supporting EAP load-balancers to divide the load among the Entrust IdentityGuard Servers
196
Document issue: 1.0

hard and soft firewalls creating a DMZ (demilitarized zone) for the Remote Access Server, and protecting internal resources an administrator to manage Entrust IdentityGuard users

197
Microsoft Windows desktop architectures

You 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 architecture

This 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 Server
198
Document issue: 1.0

Entrust IdentityGuard Desktop for Microsoft Windows installed on a computer
Microsoft Windows desktop - standard architecture

The 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 Entrust IdentityGuard Server firewall Entrust IdentityGuard Desktop for Microsoft Windows installed on users computers an administrator to manage Entrust IdentityGuard users

199
Microsoft Windows desktop - high availability architecture

The 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
Firewall
Distributed domain with Active Directory Entrust IdentityGuard
Load -balancing cluster Administrator Entrust IdentityGuard
Requirements
distributed domain configuration with replicated user repository Entrust IdentityGuard Servers load-balancers to divide the load among the various Entrust IdentityGuard Servers firewall
200
Document issue: 1.0

Entrust IdentityGuard Desktop for Microsoft Windows installed on users computers or laptops an administrator to manage Entrust IdentityGuard users

201
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.
Requirements
directory and/or database on a dedicated server for the user repository Entrust IdentityGuard Server 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 an administrator to manage Entrust IdentityGuard users
202
Document issue: 1.0

Self-Service architectures
As 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 accountstasks 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 architecture

The 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.

203
Requirements
directory and/or database on a dedicated server for the user repository Entrust IdentityGuard Server 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
204
Document issue: 1.0

are deploying Entrust IdentityGuard Mobile with the transaction notifications (pop-up alerts), which is a sub-feature of the transaction verification feature. hard and soft firewalls creating a DMZ (demilitarized zone) for the Web server, and protecting internal resources 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 Module OR must redirect requests on the standard HTTPS and HTTP ports to the Self-Service Modules 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 architecture

The 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.

205
Requirements
directory and/or database on a dedicated server to contain Entrust IdentityGuard user accounts Entrust IdentityGuard Server a Self-Service Module with the Self-Service component installed. an authentication application that makes use of the Entrust IdentityGuard API to deliver second-factor authentication 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
206
Document issue: 1.0

Self-service - soft token architecture

The 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.

207
Requirements
directory and/or database on a dedicated server to contain Entrust IdentityGuard user accounts Entrust IdentityGuard Server 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). an authentication application that makes use of the Entrust IdentityGuard API to deliver second-factor authentication hard and soft firewalls creating a DMZ (demilitarized zone) for the Web server, and protecting internal resources 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 Module OR must redirect requests on the standard HTTPS and HTTP ports to the Self-Service Modules 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
208
Document issue: 1.0

Self-service - high availability architecture

For 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 Modules Configuration interface. Figure 53: High-availability Self-Service architecture

209
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.
210
Document issue: 1.0

Federation Module architectures

As 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 architecture

The 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 users 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.)

211
Figure 55: Federation Module - enterprise architecture
212
Document issue: 1.0

Requirements
directory and/or database on a dedicated server to contain Entrust 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 architecture

The 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 users 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.

213
Figure 56: Federation Module - SaaS with high availability architecture
214
Document issue: 1.0

Requirements
directory and/or database on a dedicated server to contain Entrust 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 configurationthere 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 corporations boundary when they authenticate.

215
Enrollment Module architectures

As 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
Requirements
directory and/or database on a dedicated server for the user repository Entrust IdentityGuard Server 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
216
Document issue: 1.0

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

217
Print Module architectures

As 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
Requirements
directory and/or database on a dedicated server for the user repository Entrust IdentityGuard Server 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
218
Document issue: 1.0

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

219
Mobile enrollment architecture

Below 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 enrollmentbasic architecture
220
Document issue: 1.0

Requirements
user with mobile device The user initiates the digital ID enrollment by clicking the Id 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. Entrust IdentityGuard Server 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.

221
222
Document issue: 1.0

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
Entrust IdentityGuard grid card usability study

For 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. This section contains the following topics: 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.
Objective
The 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
224
Document issue: 1.0

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.
Methodology
The 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 results

The 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.

225
Figure 60: Successful login attempts

2nd try 29%
1st try 71%
Figure 3: Enterprise initial authentication attempts
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.
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.
226
Document issue: 1.0

Recommendations
Based 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. This section contains the following topics: General guidelines on page 227 Grid card design and layout on page 227
General guidelines
You 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 layout

Consider the following recommendations for grid card design and layout.
Fonts
Given 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 color
Given 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.

227
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.
228
Document issue: 1.0

Grid authentication implementation

This section provides more information on what the study determined about implementing grid authentication. This section contains the following topics: 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 method

Given 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 length

When 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.

229
230
Document issue: 1.0

Index IndexIndex 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
A
activation of grid cards and tokens 165 ActiveX for machine authentication 72 Administration interface 92 Administration service 32 administrator 92 alerts see transaction notifications alias 93 alias in a consumer deployment 94 Android 147 anonymous grids 132 application data 67 application integration 102 architecture consumer 203 evaluation 177 Federation Module 211 for VPN, OWA 205 high availability 178 overview 177 self-service enterprise 205 standard 177 audit database 90 audit reporting 90 authentication benefits 25 definition 25 first-factor 48 methods 49 multiple factors 25 overview of authentication methods 42 single sign-on 33 skip first-factor 48 authentication API 102 authentication factor. See authentication methods authentication methods 41 comparison 44 external 48 grid 51, 121 grid replay 64
image or message replay 65 knowledge-based 58 machine 67 machine authentication 59 mutual authentication 64 one-time password (OTP) 60 passcode list 56 password 47 Radius server 47 smart credential 83 temporary PIN 78 token 49, 143 transaction 49 authentication secret 105 Authentication service 31 automation 142
B
backup and recovery 89 baseline architectures 175 BlackBerry 147 Braille grid card 136 branding tokens 148
C
challenge grid 52, 126 least-used cells 126 lock out 97 passcode list 56 random 126 size 125 token 144 client application 38 cloud services 211 components 29 Entrust IdentityGuard Desktop 36 ISAPI filter 38
231
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
Radius proxy 35 Remote Access Plug-in 37 repository 34 server 30 computer identity 67 confirmation transaction 79, 145 cookie for machine authentication 67 Customer support 18 Entrust IdentityGuard ISAPI filter 38 Entrust IdentityGuard Mobile 50, 79, 145 see also soft tokens Entrust IdentityGuard Radius proxy 35 Entrust IdentityGuard Remote Access Plug-in 37 Entrust IdentityGuard Self-Service Module 32 Entrust IdentityGuard Server 30 Entrust IdentityGuard Soft Token 42, 45, 50, 51, 144, 147, 148, 162, 172 architecture 207 see also soft token Entrust tokens 49, 143 evaluation architecture 177 external authentication 48
D
database 109 for storing audits 90 delivery of grid cards and tokens 165 delivery of one-time passwords 60, 61 deployment of Entrust IdentityGuard overview 86 planning 85 deployment, multinode 209 desktop architecture evaluation 198 high availability 200 standard 199 Desktop for Microsoft Windows 36 directory repository 108 enroll users from directory 108 map contact info from directory 108 suspend expired and disabled LDAP users 108 disaster recovery 115 DisplayCard Tokens 50 distribution of grid cards and tokens 165
F
failover 115 advanced multi-site 119 geographically-dispersed repositories 118 local repository 117 multi-site 118 Radius server 120 repository 117 scenarios 115 Federation Module 33 architecture 211 file transmission 141 with end-to-end encryption 141 with secure email 141 with secure FTP 141 with SSL 141 fingerprint, machine fingerprint 72 firewalls first-factor authentication 25, 35, 48 flash object for machine authentication 67 FTP 141
E
eGrid distribution 128 distribution in Self-Service Module 128 security 135 email, secure 141 end user. See user end-to-end encryption 141 enroll users from directory 108 enrollment 162 from LDAP repository 163 LDAP users 108 Entrust IdentityGuard Administration service 32 Entrust IdentityGuard Desktop for Microsoft Windows 36
G
Getting help 18 grid automating 142 cell entropy 123 cell format 122 challenge 52 challenge algorithm 126 challenge size 55, 125
232
Document issue: 1.0
deployment risks 55 distribution 128 format 122 lifetime 55, 123 location replay 64 one-step authentication 52 passcode list 56 replacement 123 sample passcode list 57 serial number 64 size 55, 122 two-step authentication 53 grid authentication 51, 121 grid card Braille 136 cost factors 139 eGrid 135 production 136 production model 127 security 135 usability study 223 grid card production costs 139 Entrust IdentityGuard Card Production Service 139 in-house 136 outsourced 137 Grid card production service 139 grid card usability study 223 recommendations 227 results 225 summary 224 grid production model 128 group 98 Web 102 wireless access portal 104 integrating UNIX or Linux server 37, 202 inventory of grid cards and tokens 165 iPhone 147 ISAPI filter 38
J
J2ME 147 JasperReports (see reports) 36 Java Phone 147 JavaScript for machine secrets 71
K
Kerberos 48 knowledge-based authentication 58 challenge size 155 exact answers 156 question qualities 151 question sources 150 security 157 selecting questions 153 word map 155
L
LDAP directory 108 enrolling users 108, 114 suspending disabled and expired users 108 suspending expired and disabled users 97 updating contact information 108 least-used cells challenge 126 life cycle 159 delivery and activation of grid cards and tokens 165 enrollment 162 maintenance 173 overview 160 renewal of authentication factors 168 replacement of authentication factors 170 usage stage 167 lock out, reset 167
H
high availability architecture 178 failover scenarios 115
I
image library on Entrust TrustedCare 66 image replay, required disk space 66 integrating applications 102 considerations 105 Microsoft Windows 103 VPN 103
M
machine authentication 59, 67
Index
233
application data 67 cookie 67 flash object 67 machine fingerprint 67 machine nonce 67 machine secret 67 machine tag 67 sequence nonce 67 with questions 149, 154 machine fingerprint 67 application data 67 Get 69 Get request 73 sources 69 machine nonce 67 machine secret 67 using ActiveX 72 using Javascript 71 machine tag 67 machine nonce 67 sequence nonce 67 maintenance 173 man-in-the-browser 79 map contact info from LDAP directory 108 master user 91 master user shell 91 Microsoft Windows desktop user 39 Microsoft Windows remote architecture evaluation 190 high availability 192 standard 191 migrating to another platform 113 migrating to Entrust IdentityGuard 114 Radius 114 migration from RSA 114 mitb attack, see man-in-the-browser mobile user 40 monitoring SNMP 90 multifactor authentication 25 multinode deployment 209 multi-site failover advanced 119 standard 118 mutual authentication 43, 64 grid replay 64 image library 66 image or message replay 65
N
network diagram, see architecture notification transaction 79, 145 notification service 79 notifications of transactions 79, 145
O
one-step grid authentication 52 one-time password (OTP) authentication 60 delivery 60, 61 OOB, see out-of-band OpenID 33 operations 89 organization authentication See mutual authentication OTP, see one-time password Outlook Web Access architecture for 205 out-of-band authentication 60 password delivery 60, 61 OWA, see Outlook Web Access
P
PAM Plug-in 37, 202 passcode list authentication 56 challenge 56 deployment risks 58, 61 length 57 production 57 sample 57 scratch cards 57 password authentication 47 people needed for deployment 88 performance repository 109 testing 111 performance testing 111 pharming 55
234
Document issue: 1.0
phishing 55 physical security 90 planning deployment of Entrust IdentityGuard 85 Pluggable Authentication Module Plug-in 202 Pluggable Module Plug-in 37 Pocket Tokens 50 policies 87 preproduction model, grid cards 132 produce-and-assign model 128 producing grid cards 136 production file pre-production model 132 transmitting 141 Professional Services 19 failover 34 performance and maintainability 109 selecting 108 synchronization 174 repository failover 117 geographically dispersed 118 local 117 RRAS user 39 RSA, migrating from 114
S
SaaS 211 SAML 33 sample Web application 44 scratch cards for passcode list 57 search bases 100 second-factor authentication 42 secure email 141 secure FTP 141 Self-Service about 203 activating soft tokens through 147 Self-Service architecture consumer 203 enterprise 205 soft token 207 Self-Service Module 32 eGrid distribution 127, 128 register questions and answers 153 use in automation of processes 142 use in migration to Entrust IdentityGuard 114 user registration 162 sequence nonce 67 shared secrets 106 single sign-on 33, 211 smart credential authentication 83 SNMP monitoring 90 soft token advantages 51 downloading and activating 147 see also Entrust IdentityGuard Mobile soft token architecture 207 soft tokens 144 software as a service 211 SSL securing user responses 31
Q
question and answer. See knowledge-based authentication
R
Radius migrating from 114 Radius proxy 35, 47, 104 Radius server authentication 47 failover 120 random challenge 126 recovery 89 remote access architecture evaluation 194 high availability 196 standard 195 Remote Access Plug-in 37 renewal of authentication factors 168 replacement of authentication factors 170 replay grid values 64 image 65 message 65 serial number 64 reports 36 JasperReports 36 PDF or CSV 36 permissions 36 repository 34 database 109, 117 directory 108, 117
Index
235
transmitting files 141 SSO 211 SSO, see single sign-on standard architectures 177 strong authentication 24 suspend disabled/expired directory users 108 system monitoring 90 life cycle 159 locking out 96 Microsoft Windows 39 mobile 40 requirements 93 RRAS 39 services 95 suspending 97 training 94 VPN 39 Web 40 user enrollment LDAP 114 user enrollment from LDAP repository 108, 163 user ID 93, 94 user self-administration Self-Service Module 32 user self-registration Self-Service Module 32, 114
T
TAN. See passcode list Technical Support 18 technology 86 temporary PIN authentication 78 length 229 testing performance 111 token assigning 146 authentication 49, 143 challenge-response mode 51 deployment 146 display card 50 entering values 144 lifetime and replacement 144 pocket 50 response-only mode 51 security 148 security and branding 148 see also soft token using multiple 144 vendors 144 topology, see architecture transaction component 79, 145 notifications 79, 145 transaction authentication 49 Transaction notifications 79, 145 troubleshooting 89 two-step grid authentication 53 typographic conventions 15
V
VPN architecture for 205 VPN architecture evaluation 183 high availability 185 standard 184 VPN user 39
W
Web architecture evaluation 179 high availability 181 standard 180 Web services 31 Web user 40 Windows Mobile 147 wireless access architecture evaluation 187 standard 188 wireless architecture high availability 189 word map for knowledge-based authentication 155
U
usability study, grid cards 223 user 39 enrollment 108, 162 groups 98
236
Document issue: 1.0

IG 100 Deploy Guide

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IG 100 Deploy Guide

Încărcat de

Drepturi de autor:

Formate disponibile

Entrust

IdentityGuard 10.0 Deployment Guide

Entrust IdentityGuard 10.0 Deployment Guide

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

Documentation feedback Obtaining technical assistance Technical support

Telephone numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Email address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Entrust Professional Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

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

Challenges of first-factor authentication

Entrust IdentityGuard components Entrust IdentityGuard server

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

Entrust IdentityGuard 10.0 Deployment Guide

Document issue: 1.0

Second-factor authentication methods Grid authentication Passcode lists

Token (and soft token) authentication

Determining the grid challenge size . . . . . . . . . . . . . . . . . . . . . . 55 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 . . . . 60 Knowledge-based authentication

Grid serial number or grid location replay

Computer registration process

Sources of machine fingerprint data

Setting authentication policies

Temporary PIN authentication Transaction verification

Using personal verification numbers

Smart credential authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .83 Planning your deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .85

Alias and user ID requirements Training users

Groups in a consumer deployment Groups in an enterprise deployment Group implementation

Analyzing your companys group needs

Entrust IdentityGuard 10.0 Deployment Guide

Document issue: 1.0

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

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 . . . . . . . . . . . . . . . . . . . . . . . 107

Performance and maintainability Performance testing strategies

Entrust IdentityGuard Server hot-standby and load-balancing

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

Physical grid card production options In-house grid card production

End-to-end encryption Automating processes

Entrust IdentityGuard 10.0 Deployment Guide

Document issue: 1.0

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

Allowing users to have multiple tokens

Using soft tokens for transaction verification Deploying hardware tokens

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

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

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

Enrolling smart credential users Delivery and activation Use of authenticators

User enrollment from LDAP user repository

Replacement of authenticators Maintenance

Remove unassigned grid cards and tokens

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

High availability architecture

Web access - evaluation architecture Web access - standard architecture

Entrust IdentityGuard 10.0 Deployment Guide

Document issue: 1.0

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

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

Usability test results General guidelines

Grid card design and layout

Mutual authentication (through displaying a authentication secret)

Entrust IdentityGuard 10.0 Deployment Guide

Document issue: 1.0

About this guide

Entrust IdentityGuard 10.0 Deployment Guide

Document issue: 1.0

Underlined blue text Courier type

Angle brackets <> Square brackets [courier type]