Does SecureLogin SSO require modules installed on backend applications and systems?

  • 7940267
  • 19-Aug-2009
  • 17-Jan-2014


SecureLogin SSO
All Versions



Some password management software (using the term loosely) such as password synchronization and password reset require modules installed on all backend systems. The key purpose of these modules is to trigger and handle password change events. I am concerned about change control and support issues. Does SecureLogin SSO require these type of modules?



One of the main advantages of implementing SecureLogin SSO is that it doesn’t require any modules on application servers and doesn’t change applications or require special APIs.

Change Control

Stress levels are sure to rise before service packing any server that is running ""non-standard"" modules. IT professionals know that any non standard software often create headaches when service packs are applied or the server configuration changes in any way. Because there is a single point of failure, if, for example, password synchronization modules stopped running on a server (e.g. after a service pack is applied or some virus scanning software is installed), there could be dramatic repercussions for users trying to access applications. If password synchronization processes fail, users will not know their password to applications and therefore won’t be able to logon to any systems. In fact, application servers could stop running altogether because of the non-standard modules you are installing with password synchronization.

Organizations that have evaluated solutions that include server based modules have complained they are expensive, complex to administer and install, and practically impossible to support. In addition, application owners will be reluctant every time you need to make a change on their servers (if they allow you at all).

With SecureLogin, client software is installed on each workstation. The client is easily installed using Novell’s ZENWorks, Microsoft’s SMS, an MSI package, or using your preferred software deployment method. No changes are made to any applications and no modules are required on any of the application servers. This is a key benefit of using SecureLogin because you don’t have the installation, upgrade, maintenance or support issues associated with ""non-standard"" modules running on your application servers. And no arguments between vendors on whose fault it is the application server has fallen over.

The SecureLogin workstation agent ""watches"" for applications that have been SSO enabled by the administrator and then retrieves the logon credentials from the Directory. SecureLogin is centrally managed using Microsoft Management Console in an ADS environment, ConsoleOne in a Novell environment, or the SecureLogin manager in all other environments (e.g. SunOne). Using these administration tools, administrators can centrally publish SSO enabled applications and customize settings. Central management combined with a workstation based agent makes SecureLogin the perfect fit.

Due to its unobtrusive approach, a successful proof of concept for SecureLogin SSO can be performed by installing SecureLogin on one workstation and SSO enabling applications without touching any backend systems.