This section describes the high-level processes for managing the life cycle of Entrust IdentityGuard end users. Since Entrust IdentityGuard is a multifactor authenticator, a user account must already exist in the first-factor authentication application (for example, user name and password). No assumptions are made about organizations’
procedures for managing user accounts.
User life cycle management consists of the following stages and processes:
1 “Enrolment” is the initial stage where users enroll for the Entrust IdentityGuard service.
2 “Usage” is the normal operations stage where users are authenticated with their Entrust IdentityGuard authentication methods.
3 “Renewal” is an ongoing stage where users are issued new Entrust IdentityGuard grids (on new cards), tokens, one-time passwords, or questions to replace older ones.
4 “Replacement” covers the handling of:
• lost, stolen, damaged, and “left behind” Entrust IdentityGuard cards, passcode lists, or tokens
• forgotten answers and one-time passwords
End users are issued temporary PINs (if using cards, lists, or tokens) or a one-time passwords, and, if necessary, receive a replacement Entrust IdentityGuard card, list or token.
5 “Delivery and activation” describes the processes to physically deliver the Entrust IdentityGuard cards, lists, or tokens (as applicable) and activate the
authentication method. It does not apply to other authentication methods.
6 “Maintenance” describes the processes to:
• Remove stale or idle cards or tokens from the Entrust IdentityGuard system.
This includes cards or tokens that are cancelled, deactivated or unassigned as well as cards or tokens assigned to terminated user accounts.
• Update machine registration.
• Remove old one-time passwords.
• Update any graphics or images used for mutual authentication.
Enrolment
Enrolment is the first stage of the life cycle whereby:
• Users are registered in the Entrust IdentityGuard system.
• Users are provided with an Entrust IdentityGuard authentication method and associated data (such as a card or passcode list).
• The authentication method is activated.
For the enrolment processes, ensure you have processes and procedures in place to create and manage user accounts and to issue the authentication credentials (such as user name and password). Depending on the authentication methods assigned to users, the following are examples of events that may occur:
• Entrust IdentityGuard grids are assigned to end users and Entrust IdentityGuard cards are produced.
• Microsoft Windows desktop users install Entrust IdentityGuard Desktop.
• Tokens are assigned to end users and mailed to them, along with instructions on activation.
• 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.
If you are using cards, passcode lists, or tokens, complete the enrolment process with
“Delivery and activation” on page 120.
Usage
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 prompt (for example, three incorrect responses). This is necessary to protect against a brute force attack whereby an attacker attempts to log in by simply guessing the correct response to an Entrust IdentityGuard challenge.
However, a legitimate user can be locked out by making consecutive errors. The Entrust IdentityGuard system will release the lock out after a defined time period (for example, 20 minutes), but this may be inconvenient to the user. The Entrust IdentityGuard administrator can also release a lock. Organizations should design their customer service procedures for this situation to ensure that proper identity
verification is performed before unlocking an end user’s account.
Renewal
You should ensure users renew their authentication data (such as their passwords, tokens, cards, and knowledge-based information) on a regular basis. Once the data has reached an expiry date or usage amount, it is important that users are not denied service.
Ensure you put a process in place that completes the following actions (when applicable) before expiry:
• a new card, passcode list, or token is issued and delivered to the user
• a new one-time password is generated and delivered to the user
• a user is redirected to a page that requests new knowledge-based information
An automated central renewal service is recommended so that you do not have to burden your staff with the overhead of administering routine renewals.
Figure 19 on page 117 illustrates the high level process steps for renewal.
Figure 19: Enterprise renewal
To renew
1 An administrator extracts information from the Entrust IdentityGuard repository, selecting users whose Entrust IdentityGuard authentication data will expire within a specified time frame. This should be done on a regularly scheduled basis.
2 To generate and assign new authentication data:
• for grids, one-time passwords, and passcode lists, Entrust IdentityGuard generates and assigns new authentication data (such as the grid) for each selected user name
• for tokens, administrators assign a new token to the user
• for knowledge-based information or image/graphic replay authentication, an application requests new information from a user when they log in 3 If applicable, produce new cards and passcode lists or order more tokens.
Card production is discussed in detail in the section “Deploying grid authentication” on page 87.
If you are using cards, passcode lists, or tokens, complete the renewal process with “Delivery and activation” on page 120.
Select users
Replacement
It is natural that Entrust IdentityGuard authentication data 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 continue to provide users with the access they need until replacement data is in their possession.
• For cards, passcode lists, or tokens, the Entrust IdentityGuard system provides a temporary PIN on an as-required basis.
• For other types of authentication data (such as knowledge-based or one-time password), your application needs to provide some means for a user to request new passwords or hints to answers.
Figure 20 illustrates the high level process steps for replacement.
Figure 20: Enterprise replacement
To replace
1 A user needs to verify their identity and start the recovery process. There are three approaches:
• Over-the-counter recovery (identity verification): In the over-the-counter approach, the user visits the service desk and requests replacement
authentication data. The service desk performs in-person identity verification to ensure that the request is legitimate. This approach is useful where a visit to the service desk is mandatory (for example, the Entrust IdentityGuard grid is printed on the back of an employee ID card).
• Self-Service recovery (identity verification): In the self-service approach, the user has access to a self-recovery application. The application performs an Over-the-counter
identity verification procedure, possibly using a question and answer system, to ensure that the request is legitimate. The questions and answers for recovery must have been created by the user during the enrolment process or through a separate application after enrolment.
• Central service recovery (identity verification): In the central service approach, the user calls the service desk and requests a recovery. The service desk performs identity verification over the phone to ensure that the request is legitimate.
2 The application or service desk administrator provides a user with temporary authentication means. If provided by an application, ensure the information is displayed in non-machine readable format.
• If using grid or token authentication, the administrator or application should suspend or cancel the current card or token, and provide the user with a temporary PIN. Cancellation is recommended for lost, stolen and damaged cards and tokens. A “left behind” card or token (for example, the user knows where the card is and it is safe from attack) can be suspended.
Attention: The cancellation process is irreversible for cancelled cards, lists or tokens. They can never be used again.
For information on temporary PINS, see “Temporary PIN authentication” on page 55.
• If using out-of-band authentication, another one-time password should be generated. Generating a new password cancels the old one.
• If using knowledge-based authentication, present hints to the user that were provided during registration, or, if that doesn’t help, issue a one-time password until the user can complete the recovery process.
3 Determine whether you need to replace or recover the authentication data.
• For cards, passcode lists, or tokens, the user may indicate whether
replacement or re-activation is necessary. If you cancel the card, list, or token, then you must replace it. Ensure the temporary PIN is cancelled when the user has successfully authenticated using a re-activated or new card, list, or token.
• If using knowledge-based authentication or image and graphic replay authentication, it is recommended that, if the information is permanently forgotten, the user reset their information by accessing a secured Web page (such as one located on your Intranet). Optionally, you can ensure that they enter a one-time password in order to verify their identity when accessing the page, or call up an administrator to complete the process.
If you are using cards, passcode lists, or tokens, complete the replacement process with “Delivery and activation” on page 120.