Misconception Perception: Single Sign On Myths Debunked

Dean Wiech (Profile)
Wednesday, January 9th 2013

Single sign On (SSO) allows end users to log in to accounts once with their credentials and thereafter enjoy immediate access to all of their applications and systems without being asked to log in again. This is extremely beneficial in reducing help desk calls since users only have to remember one password instead of many.

Though SSO can be beneficial to any company, many IT managers and security officers are skeptical about the implementation of an SSO solution. Their skepticism is the result of a number of preconceptions, which in many cases are misconceptions, about these identity and access management tools.

The following are the many incorrect common beliefs about SSO:

Implementing SSO Imposes Greater Pressure on Security

IT managers and security officers often believe that with one-time logging in to accounts security of information is immediately placed at risk. They assume that if an unauthorized person gets hold of that single log-in credential, that person will have access to all the account’s associated applications.

When using SSO, all the various access entries to applications are replaced by one access point. For example, the software allows users to use just one password for multiple accounts. Once the password is entered, all accounts are accessed. Though this does appear to constitute a risk, the log-in process is actually streamlined for the user. Having to remember just one password essentially does away with the risk that the user will scribble passwords on a piece of paper and place them under their keyboard (as is often the case) like they might if they have to remember 12 password and username combinations (the average number per user) that most users have without SSO.

This was often the case at Community Bank and Trust of Florida. Since the bank uses hundreds of different systems and applications that require complex passwords, users understandably had a difficult time remembering all of their user credentials. By implementing SSO at the bank, end users no longer have to use unsecure methods, such as writing down their passwords to remember them.

It is also possible to add extra security to the primary SSO log-in with a user card and pin code or an extra-strong password. Logging in with a card and pin code is an extremely secure authentication, and users also consider it to be very user-friendly.

An SSO Implementation is a Long, Drawn Out Project

This is often wrongly assumed because SSO implementation is part of a broader security policy. Other components might include introducing more complicated passwords, taking more care with authorizations and complying with standards imposed by the government.

Because SSO affects almost all end users and runs throughout the organization, some see implementation as taking a great deal of time to notify and prepare end users for the change. SSO brings with it a number of questions, such as:

  • “How do I deal with people who have multiple log-ins on one application?”
  • “What do I do if an application offered through SSO gets a new version?”
  • “What happens if the application itself asks for a password to be reset?”

All these questions often cause SSO implementation to be shifted to the background. However, any potential complexity faced at implementation is no reason to postpone adding a SSO solution because it has long-lasting benefits once up and running. By starting small, say by making the top five applications available through SSO, a considerable time saving on the number of log-in actions can be achieved, justifying buying the solution.