Single Sign-On Technology: Friend or Foe?

19 Apr 2022

Single sign-on authentication technology offers numerous benefits and conveniences, but proper implementation is required to enhance security

Single sign-on (SSO) is an authentication scheme designed to facilitate access to multiple independent protected resources, such as web applications, using a single set of credentials via a trusted identity provider (IdP). It has various benefits including reduced password fatigue (as the same credentials can be used for multiple resources), a more streamlined workflow (i.e. increased productivity) for both users and administrators, not to mention reducing the attack surface due to the direct impact on the number of credentials available for adversaries to compromise. It sounds great, in theory. But just how secure is Single sign-on?

One of the most common SSO configurations utilises Security Assertion Markup Language (SAML), a form of the widely used Extensible Markup Language (XML), to exchange authentication details with the trusted identity providers (e.g., Microsoft, Google etc). Here's how it works.

First, the user attempts to access a protected resource let's assume this is a web application. The application doesn't recognise the user, so asks a trusted identity provider to verify their identity. In practice, this usually involves being redirected to a company sign-in page, an activity not unusual for anyone employed by a large organisation. Once logged in, the user is provided with a SAML Response that is passed to the web application with which to authenticate. This all takes place behind the scenes to provide the user with a seamless login experience.

So what exactly is an SAML Response?

To put it as simply as possible, an SAML Response is a nested data structure containing all the information the application requires to authenticate the user. This can include various details, but most commonly features the account username in the form of an email address. This is known as an Assertion. As the application has entrusted the identity provider with verifying the identity of the user, it implicitly trusts the contents of the SAML Response.

What would happen if someone were to modify the SAML Response?

Fortunately, this obvious loophole has been considered, resulting in strong cryptographic techniques being used to 'sign' the Response. Any modifications to the Response would result in an entirely different cryptographic signature, causing the SAML Response to be rejected.

However, not all implementations are equal. There is a wide range of solutions available to handle SAML Responses, not to mention those designed in-house, which as it turns out can be easily misconfigured resulting in a plethora of techniques by which to subvert the application logic.

For example, let's say an SAML Response contains an Assertion. The Assertion is signed to ensure it cannot be tampered with. However, what would happen if we inserted another malicious Assertion, prior to the original, into the Response? The application may not be expecting multiple Assertions. In this case the logical thing to do would be to only process the first (malicious) Assertion. We have now authenticated as a user of our choice, a devastatingly simple method of account takeover.

The solution to this would be to sign the overall Response, rather than just the Assertion. Seems airtight? Unfortunately, this logic could still be subverted. Due to the nested nature of XML, the original SAML Response could be included as a child element of yet another malicious Response. The cryptographic signature remains unchanged and arbitrary Assertions can be inserted into the malicious Response. This is known as XML Signature Wrapping (XSW), a lesser-known attack of which many variations exist.

Single sign-on is effective if implemented properly

SSO can be a force for both increased security and productivity. But correct implementation and configuration are vital.