SecureLogin has features for single sign-on security systems. They include support for Public Key Infrastructure (PKI) encryption of single sign-on credentials and the option to use Advanced Encryption Standards (AES) for encrypting data. Both these features require changes to the SecureLogin single sign-on data format to support them.
The SecureLogin client can read data created with all the previous versions of SecureLogin. However, older versions of the product cannot read data created by SecureLogin 8.0. This means that in a mixed environment where some computers are running SecureLogin 8.0 and some other computers are running a previous versions, issues are likely to arise when users move between these versions.
This is especially a problem in Citrix Environments, or in large enterprise deployments.
The last data format occurred in SecureLogin 3.0. x and 3.5, and was related to the introduction of new scripting types and other features.
The impact of disruption of data upgrades like this is high. Hence, several new features are included in the version 6 data format that minimizes the disruption caused by data upgrades in the future.
While trying to install SecureLogin 7.0, it detects that SecureLogin 3.5 data is in use and continues to work. In this mode, all 3.5 functionality continues to be available, but any version 7.0 functionality that relies on the new data is not available.
Significantly, this includes smart card support and AES encryption of data.
If you do not require functionality of the new version, then there is no great impetus to upgrade the data format. If, however you require the functionality of the new version, then complete the following tasks:
Choose a section of the tree to upgrade.
Ensure that all workstations used by users in that section of the trees are upgraded to the SecureLogin 8.0 client.
The next time these users log in, their data is converted to version 7 format and, the new features are available.
NOTE:When a user with SecureLogin 3.5 data first loads the version 7 client, they are prompted to answer the Passphrase question.
This does not happen if the passphrase system is disabled while the user was operating on a version 3.5 client.
The new single sign-on security system stores additional passphrase information to facilitate seamless upgrades in the future. It now uses a more secure key derivation technique and allows the use of AES. The passphrase data stored in version 3.5 format does not contain the information required to support these new features, so, the users are prompted to reenter the passphrase answer.
In the future, new single sign-on features might be desired. For example, the directory password and smart card might be used to protect single sign-on credentials, or a system might be available where a designated administrator can unlock a user’s credentials after a password reset is done. In these cases, a new keywrapper type is needed. They keywrapper is ignored and not interpreted by the version 7 client, but the version 6 client can still access data using the old keywrappers that it does understand. This means that as long as the standard keywrappers are defined there are no upgrade issues with version 7. However, in a scenarios where the keywrappers are not defined, the existing data format upgrade process is applicable.
If you need to use the encryption algorithm, you must upgrade tot he version supporting that algorithm. However, there is no need for customers to upgrade if a particular algorithm is working for them.