Enterprise single sign-on (E-SSO) systems minimize the number of times that a user must type their ID and password to sign into applications.

Most enterprise single sign-on systems work as follows:

  • E-SSO client software is installed on user PCs.
  • Users sign into their PC using a password or other primary credential.
  • A local or network file, database or directory is used to store application login IDs and passwords for each user. This is often referred to as a "password wallet."
  • When a user launches an application, the E-SSO client software automatically fills in the ID and password fields in the login screen with credentials from the aforementioned "wallet."

The password wallet is often encrypted, normally with a key derived from the user's primary password. Where users sign into their PC with a smart card, a private/public key pair is used to encrypt the wallet. Where other types of credentials, such as proximity badges or biometrics, are used to sign into the PC, wallet encryption is necessarily based on a retrievable password and the overall scheme is insecure.

E-SSO software acts as a surrogate for the user: storing, retrieving and "typing in" the user ID and password on behalf of the user. The user continues to have multiple ID/password pairs, but does not have to type them manually and may not know what they are.

When applications prompt users to change their passwords, E-SSO systems often choose a new, random password and store that in the password wallet. This results in a situation where users no longer know their own application passwords, so are totally reliant on the E-SSO system to sign into applications.

Previous approaches to enterprise single sign-on systems had problems, mainly related to the password database where application login IDs and passwords are kept:

  • Remote Access and Mobile Devices:

    Over time, a traditional E-SSO system will respond to applications expiring passwords by choosing new, random password values, allowing the application to change passwords and storing the random password value for future reference.

    With this process in place, over time users lose knowledge of their own passwords and become dependent on the E-SSO system to sign into their applications. This means that users cannot access their applications from devices that are not equipped with the E-SSO software, such as smart phones or even their home PCs.

  • Cost to Deploy:

    Building and maintaining a database of every login ID and every password on every application can be both costly and time consuming.

  • Cost to Reset Passwords:

    Login IDs and passwords stored in a traditional E-SSO system are typically encrypted using a key derived from the user's primary network password. When users forget their primary password, they lose this key and can no longer decrypt their application passwords. As a result, password problems may be less frequent with E-SSO, but resolving them is more complicated, time consuming and expensive.

  • Security and Availability:

    In the event that the password database in a traditional E-SSO system is compromised, every user ID and every password would be exposed.

    If the password database suffers an outage, every user would be locked out of every application.

In addition, traditional SSO systems have to integrate with a variety of subsystems on the user's PC, both to detect when a password prompt is displayed and to inject passwords into input fields. This requires integrations with:

  • The login subsystem on 32-bit and 64-bit editions of Windows (XP, Vista, 7, 8, 10, etc.).
  • Applications built using native Windows dialogs.
  • Applications built using frameworks such as Java AWT or Swing, which appear to the Windows OS as just bitmaps.
  • Web applications, rendered using any version of any web browser.
  • Unix or Linux applications, rendered in a terminal emulator such as PuTTY or SecureCRT.
  • X-Windows applications, rendered in an X Server such as Ming, Cygwin/X, VcXsrv or many others.
  • Applications on IBM z/OS mainframes or iSeries midrange servers, rendered in a TN3270 or TN5250 terminal emulator.
  • Undoubtedly, others...

Some organizations require integration with other platforms -- MacOSX, Android, iOS and Linux, which significantly expands the scope of the problem.

Each of these components operates totally differently than the others and has its own release cycle. Web browsers such as Chrome and Firefox, in particular, release new versions every 6 weeks or so, which often break backwards compatibility.

The net result of this complexity is that it is quite difficult to maintain compatibility across a variety of applications as various application development frameworks constantly evolve. Customers are impacted in that they are either prevented from upgrading their endpoints (as this would introduce breakage), or having to frequently upgrade their SSO software, or suffering frequent compatibility problems because upgrades to applications cause SSO to stop working.

Hitachi ID Login Manager, a module included with Hitachi ID Password Manager, is an enterprise single sign-on solution. It automatically signs users into applications where the ID and/or password is the same as what the user typed to sign into Windows.

Login Manager leverages password synchronization instead of stored passwords. This means that it does not require a wallet and that users can continue to sign into their applications from devices other than their corporate PC -- such as a smart phone or tablet -- for which a single sign-on client may not be available.

Login Manager does not require scripting or a credential vault, so has a much lower total cost of ownership (TCO) than alternative single sign-on (E-SSO) products.

Return to Identity Management Concepts