Are there any changes to applications, additional services, or additional hardware required to run SecureLogin?

No, there are no changes made to applications or additional services required for SecureLogin to operate.

Because SecureLogin leverages your existing infrastructure security and choice of Directory (e.g. ADS – including ADAM, eDirectory, SunOne, Critical Path) it does not require additional hardware to operate, making it extremely scalable and robust, and easily deployable.

SecureLogin does not require services running on a server or changes to application executables, dynamic link libraries, initialization files etc. Because SecureLogin does not touch backend systems, it is easily integrated with any application and does not create political, change control or support issues.

By simply deactivating the SecureLogin icon in the system tray, the workstations, applications, and application servers will function exactly as they did before SecureLogin was deployed, making it much easier to troubleshoot, support and maintain.

While SecureLogin requires no new hardware and leverages your existing infrastructure, other solutions may require new hardware in the form of a servers or appliances that store Single Sign-on data. Of course, the appliance must be secured, installed, replicated, configured, maintained, backed up and supported. The number of servers or appliances required increases with the size of your organization, since access to Single Sign-on data is typically required locally. For example, if you have offices in Sydney, London, and New York, a primary device, and another for fail over, should be installed in each location, adding to the cost and overheads associated with your Single Sign-on project. And these devices would have to be replicated.

The only time extra hardware is required is when you wish to integrate SecureLogin with strong authentication devices such as smart cards, biometrics and tokens.

Note: SecureLogin is extremely scalable and flexible. If you prefer to have a dedicated Single Sign-on server or “appliance” or Single Sign-on data stored in the file system instead of the Directory, although it is not recommended due to the overheads outlined above, this can be easily achieved.