Single Sign-On is great - it makes it easier for users to access applications. So why do SaaS vendors often charge a premium for it? Surely they should want as many users as possible to login to their applications?

‍SaaS providers do this because they know the truth behind this common misconception about Single Sign-On (SSO).

Single Sign-On is no longer just a 'nice to have'

SSO originated nearly 20 years ago, out of a desire to make users’ lives easier when logging in to the first crop of corporate SaaS applications. Why login separately to applications, when you’ve already signed in to your computer first thing in the morning?

The last decade though has seen a revolution in how people access IT systems, and the last six months has accelerated this even further.

If you’ve not guessed already, that revolution is remote working: the need to access IT systems from mobile devices and non-office locations.

SSO has become central to modern IT security approaches to remote work. And meeting IT security needs is an easy way for SaaS vendors to generate additional revenue.

To understand what’s behind all this, we need to first look at a bit of IT security history.

IT teams need to adapt their perimeter defenses to keep pace with a changing workforce

IT organizations have traditionally used the “castle” metaphor to model IT security, otherwise known as perimeter security. The idea is that by defending the edge of your network you create a safe space in the middle.

The traditional perimeter is the physical office network. If you’re in the office you can connect to the finance system; if you’re at home, you’re not on the network, so you can’t.

Multiple offices means connecting individual office private networks, typically with “tunnels” (sending encrypted data over the public internet). Installing Virtual Private Network (VPN) software on a laptop lets staff connect to the office network from other environments.

Mobile devices started to show the limits of this approach. Whilst laptops are typically company-owned assets, employees generally have their own mobile phones and don’t want to carry two handsets.

Using your phone to access work tools is called BYOD (Bring Your Own Device). It means IT needed to start setting up and managing company software (including VPNs) on staff-owned handsets. This heralded the Mobile Device Management (MDM) wave. MDM tools help keep track of tablets and phones, particularly to help remotely delete company-owned data and enforce other security measures. MDM has since expanded to cover other devices such as laptops and servers and is now known as Endpoint Management.

This brings us to the present day.

Zero Trust - the intersection of SSO & Endpoint Management

The intersection of Single Sign-On and Endpoint Management tell you who is trying to connect, and the state of the device they are using. Is it really the right user, and is their device patched and virus-free?

This combination is behind the latest generation in IT security thinking — Zero Trust. Zero Trust declares that the castle walls have fallen.

Firstly, the castle walls were getting more and more permeable as people started using their own phones and tablets to connect to company networks. The zone we thought was trusted (the corporate network) can’t be trusted anymore.

Secondly, the rise of Cloud Services, means that company data is increasingly being stored in SaaS applications and platforms like AWS or Azure so it’s very hard to enforce any kind of perimeter.

The massive shift to remote work driven by COVID-19 is the final nail in the coffin. The office has gone, and the perimeter has exploded.

Ensuring that every company laptop and phone has complicated VPN software installed and working is hard-enough, but VPNs can also place a tremendous burden on company networks. Imagine squeezing every employee’s web traffic through the narrow data-pipe going into the company network. It’s not pretty.

What do we do, in this age without castle walls?

According to Zero Trust, we need to be flexible. In the real-world we make decisions around trust based on context.

If a friend asks you to borrow some money, are you more likely to agree if:

  1. you’re sitting looking at each other
    or
  2. you get a poorly worded message on Facebook (allegedly from your friend), asking to send them some money via Western Union.

Context matters.

The same thing applies to IT security.

If I’m connecting to the finance system from a company owned laptop (identified by our Endpoint Management tool as up to date with all patches), and I’m connecting from the same network address that I’ve used many times before, then I’m probably pretty trustworthy.

If the request comes from a non-company owned computer, located in a country thousands of miles away from my normal work location then maybe some additional checks are warranted.

One simple additional check is using a secondary form of authentication such as a one-time passcode generated by a mobile phone “authenticator” application, or a security-key (such as those from Yubico).

This sort of technology is called Adaptive MFA (Multi-factor Authentication) — it makes access easier for users when the risk is lower, and increases checks when the stakes are higher.

There’s all sorts of risk analysis techniques that can be applied here. Common risk scoring methodologies include not just looking at past physical location, or whether the device is known, but also watching for connections at unusual times of day, or whether this is an application the user accesses regularly.

All of this relies however on doing these access checks at minimum when someone logs in to an application.

If you are using Single Sign-On across your application portfolio, then you can apply these policies centrally through your Identity Provider (IdP). You’re not reliant on individual applications supporting these complicated technologies, and the IdP has a broader overview of user access patterns to assess risk.

That’s why Single Sign-On is so important, and it’s why many SaaS vendors know that you’re likely to pay extra for its benefits.

Taking this further depends on your IdP. If you have G-Suite then take a look at Context-Aware Access, for OneLogin it’s SmartFactor Authentication, for Okta check-out Sign-On policies, and for Azure AD Conditional Access policies.

True Zero Trust models go even further. Google was one of the first organizations to implement such an approach back in 2014, with their “BeyondCorp” project. One of the tenets of this is to authenticate every request, not just every login, but this requires more complicated configuration.

Regardless of whether you’re Google or not, you have to start somewhere. Putting your IdP and SSO front and center of your SaaS security strategy is a key first step.