Single sign-on: solving the password proliferation problem

Having multiple passwords combined with numerous redundant sign-on processes poses both a security risk and a productivity loss for business. A single sign on system is the answer.

The use of cloud-based applications such as Salesforce CRM, Concur travel and expense management and WebEx conferencing has become commonplace in many organisations. Requiring employees to sign on individually to each system they use presents several problems, all of which are avoided by using single sign-on (SSO).

Efficiency and convenience

Having to repeatedly sign on to various systems is irritating at best, and can be downright frustrating as it gets between people and their work. Imagine how much more convenient it would be if signing on to a computer or other device automatically gave you access to all the systems you were entitled to use.

That should also reduce the number of password resets required, as users only need to remember one password at a time. While many organisations have automated that function to take the load from helpdesk staff, the productivity impact on users is not merely the time it takes to perform the reset itself - the interruption to the flow of work causes a loss of focus, and it can take longer to pick up the thread again than it did to reset the password.

In addition, the more convenient it is to use officially sanctioned applications (eg, because they come under the SSO umbrella), the less likely people are to use unapproved software in an attempt to complete tasks more easily.

Security

The more times during a day that someone needs to enter a password, the more likely they are to pick one that’s as simple as possible to type. But unless they are inclined towards security, they’ll typically select one that barely meets the mandatory minimum length, and that requires as little use of the shift key as possible.

They will often use that same password on different systems as most of us find it impractical to remember more than a handful of passwords (password management software can be useful - see Is a password manager right for you?), so an intruder who is able to determine a person’s credentials in one place (eg, via the recent Heartbleed vulnerability) will try using them in others.

But if the point of SSO is that you use one username and password, doesn’t that mean it suffers from the same drawback? On the face of it, once you’ve discovered a user’s credentials you can get into all the connected systems. The difference is that with SSO those credentials aren’t stored on all of those systems. Rather, the SSO system testifies to all the others about the user’s identity. But there is an element of putting all the eggs into one basket, so it is important to ensure that the SSO system is a stronger basket.

Another side to this issue is that SSO reduces the opportunity to steal passwords. SAML (Security Assertion Markup Language) based approaches mean that passwords do not travel between systems, so passwords cannot be ‘sniffed’ locally or remotely as they traverse networks, and there is nothing to steal from the remote systems.

The centralised nature of SSO provides an opportunity to implement two-factor authentication in a context-sensitive way. You might decide, for example, that the password alone is sufficient for login attempts originating from organisation-owned devices that are on the premises, that the second factor is mandatory when logging in from outside Australia and required intermittently for locations inside our borders.

Identity

Why do we sign on to systems? It’s basically a way of establishing who we are. Not absolute proof of identity, admittedly, as people have been known to walk away from computers without signing out, to peek when their colleagues are typing their passwords or to deliberately share credentials including devices used for two-factor authentication.

Most organisations of any size already have a mechanism based on Active Directory or LDAP for controlling access to particular systems according to a person’s job. Depending on the organisation, all employees may need an email account and limited access to the HR system so they can lodge holiday requests. Managers will need a higher level of access to the HR system to approve or reject those requests, and probably to the ERP system to keep tabs on any expenditure for which they are held responsible.

An SSO should interoperate with these identity and provisioning systems to minimise the administrative effort required, so that access to cloud-based systems is controlled in the same way as it is for internal systems.

In addition to simplifying things when a person joins or leaves the organisation or has a change of responsibilities, integration between an SSO system and Active Directory (or similar) makes it easier to demonstrate compliance with policies concerning access rights.

So why isn’t selecting an SSO system simple?

Universality

It might sound obvious, but you only want one SSO system in your organisation, otherwise it’s going to cost you more, be harder to manage and probably won’t deliver the full benefits to users.

It is usually important that the system handles cloud (SaaS) and on-premises applications, and also mobile apps, so make sure the SSO system you are considering provides broad support. In particular, if you are using any SaaS applications that require the entry of a username and password via a web form, ask potential SSO providers whether they offer a mechanism to securely store or access these credentials for delivery as required to such programs.

On the mobile side, SSO is often handled by an app that automatically handles sign-on to web applications. Some device vendors provide an API that makes it easy for developers to support SSO in their apps.

Mobility

Apart from the mobile-related issues discussed above under universality, there’s a particular issue around mobility in that SSO intersects with mobile device management (MDM).

One of the basic tasks of an MDM system is to provision certificates such as those required for Wi-Fi or VPN access. Mobile SSO also requires certificates, so it is important an SSO system can leave provisioning them to whichever MDM system is in use or handle the job itself where necessary. Having this capability also opens the door to using what is primarily an SSO system as your MDM tool, if the system provides the additional features either as a standard part of the product or as one or more optional extras.

Broad support

BYOD has largely been the rule as far as smartphones are concerned (depending on your industry, the idea of a company-issued phone might be completely alien), and in many occupations there is a growing expectation that some out-of-hours work will be involved. So an SSO system should work on any operating system staff are likely to use - at a minimum, Windows, OS X, iOS and Android, and in some segments support for Linux might be expected.

Security

If an SSO system unnecessarily duplicates the functions of an existing Active Directory or similar infrastructure, it increases the attack surface whether the additional server is on premises or in the cloud. Ensuring that the SSO system obtains the information from Active Directory (and so on) as and when it is needed provides better security, a simplified architecture and lower cost.

Policy

What happens when you don’t use Active Directory or similar (eg, a relatively young organisation may have made a deliberate decision to go ‘all cloud’, completely avoiding all on-premises servers) or you need to manage users who are excluded from Active Directory (eg, contractors)? In such situations it is a big advantage if the SSO system incorporates its own facilities for defining and applying policies.

Administration

Close integration with Active Directory can also make life simpler for administrators. Since the right to access a particular resource (eg, an application) is determined by the security group(s) the user belongs to, administrators are starting off in familiar territory. The benefits of that familiarity can be maximised if the SSO system provides plugins so that administrators can control some or all of its functions from within Active Directory tools.

And if those familiar tools can be used to manage all of the computers and mobile devices present within the organisation, regardless of their operating systems, the complexity of the administrative environment is reduced. Less complexity means less training and fewer errors.

Summary

SSO means your employees don’t need to remember multiple passwords and aren’t required to log in each time they use a different system or application. The organisation benefits from improved security, better auditability, simplified onboarding and offboarding, and increased productivity.

But not all SSO systems are created equal. Before adopting a particular system, make sure that it covers all the functional bases (eg, support for mobile apps as well as browser-based access from PCs and support for the platforms used or likely to be used within the organisation), works alongside existing systems such as Active Directory and MDM, avoids unnecessary duplication of security-critical data and - to the extent possible - provides administrators with familiar tools.