7.5 Lost Card Scenario
The option determines how SecureLogin handles a user forgetting, losing or damaging their smart card. The Lost card scenario option can only be used if, and only if, the has been enabled (the or options).If the lost smart card is being used to encrypt SSO data and key escrow/recovery is not used, the user does not have access to SSO data unless is set to or .
If is set to , if the user has previously set a passphrase, and if is set to , the user is prompted to answer his or her passphrase before SecureLogin is available.
If is set to , the user is not prompted for the answer and SecureLogin loads seamlessly.
For more information on other lost, forgotten, or damaged smart cards, refer Section 7.6, Using a Card Management System.
Figure 7-9 Lost Card Scenario
7.5.1 Requiring a Smart Card
The option prevents a user from starting SSO without his or her smart card. This option is for high security implementations where organizations want to tie the use of a user's SSO credentials to the user's smart card. This means that the user cannot access SSO with any other method; that is, they cannot use a username and password without the smart card.
IMPORTANT:If the option is changed while the user is logged on, refreshing the cache using the > option from the taskbar does not refresh the option.
The user must log out and log in again (or restart SecureLogin) for the new option to take effect.
7.5.2 Allowing a Passphrase
The option must be used in conjunction with the option. It allows the user to start SecureLogin by using a passphrase if the smart card is not available. The passphrase security system must be set to or for this setting to apply.
The option replaces a user-generated passphrase with a system-generated passphrase, effectively removing the need for the user to remember the passphrase answer.
IMPORTANT:For the user to decrypt data using a passphrase, the passphrase must already be set. You cannot simply toggle the on the day the user forgets a smart card unless the user has previously set a passphrase (or had it randomly generated using the option).
7.5.3 Temporary Access Using Passphrases
There are a number of options available that permit access if a user loses or forgets his or her smart card. For example, If a user loses or forgets his or her smart card and the option is set to , you can grant temporary access to systems by resetting the user's password. The user is then required to log in and enter the passphrase. This option is possible only if the is turned on.
However, the user should not expect easy or automatic access to the system. Users should understand that, a strong and secure solution has been implemented and that they have the responsibility of looking after their own smart cards.
7.5.4 Access Without Suitable CMS
If an enterprise opts to deploy corporate smart cards without a suitable CMS based user key escrow, archiving and backup system combined with a very high level of security by setting to and setting options of or options. In the event of a lost or damaged smart card the user will never be able to decrypt their SSO data because the key stored on the smart card is not recoverable.You will need to delete the user's existing SSO configuration data store from the > tab.
Deleting the user's SSO datastore will permanently delete all the user's corporate enabled applications, credentials, options and user policies.
You must then reset the user's corporate passwords and issue a new smart card (with a new key pair) before the user can log on and reconfigure the SSO applications using SecureLogin again.
The user will have to manually enter all their application credentials into SecureLogin the first time this is used after having cleared them from the directory.
7.5.5 Restoring a Smart Card Using CMS
It is recommend that enterprises consider implementing key escrow/archiving/backup via a suitable CMS that will allow a user's encryption key to be recovered in the event of a lost or damaged smart card. The use of a CMS is crucial if an enterprise opts to deploy corporate smart cards with a very high level of security by disabling the combined with using the set to and the data options of or .
In the event of a lost or damaged smart card, the user will never be able to decrypt their SSO data because the key stored on the smart card is not recoverable.
IMPORTANT:It is recommended that you extensively test the CMS and smart card restoration techniques before selecting the high security options described above that tie SSO to the user's smart card.
7.5.6 PKI Credentials
If the data option is set to use to encrypt a user's SSO data and is set to , in the event of a lost or damaged smart card the user will never be able to decrypt their SSO data because the key stored on the smart card is the only key that can be used for decryption and is not recoverable unless key archive and recovery is implemented.
If a CMS based key archive is used then the encryption key needs to be recovered to the new smart card, the SSO data unencrypted and an administrator needs to chose a new certificate to encrypt the users data.
Using the enterprise CMS based recovery system, the administrator must issue the user a replacement smart card based on a CMS backup of the user's original key.
7.5.7 Key Generated On Smart Card
Similarly, if the data option is set to use to encrypt a user's SSO data, then in the event of a lost or damaged smart card the user will never be able to decrypt their SSO data because the key stored on the smart card and is not recoverable.
You should consider setting the option to when the option is used to provide an alternative mechanism for decrypting SSO data if the smart card is lost/stolen/damaged.
Using the enterprise CMS based recovery system, the administrator must issue the user a replacement smart card based on a CMS backup of the user's original key. The replacement card will include the recovered private key and a new key pair so data can be decrypted using the old key and re-encrypted using the new key.