Understanding the fundamentals of Single Sign-On systems (SSOs)

Organisations that operate multiple web-based systems (websites, mobile applications, CRMs, events management systems, marketing platforms, etc) often encounter a common issue: people use multiple systems or tools, and each system has its own method of authenticating users and storing their profile information. 

This creates challenges for both the organisation's technical managers and the users themselves - and this is where Single Sign-On systems (SSOs) come in.

Who needs to know about SSOs? 

We often work with large organisations that have a wide range of websites and web applications. In this type of environment, it is crucial to have a centralised system to store and manage user data and authentication credentials. This ensures that user information remains consistent across all systems, whilst keeping those systems (and the data they hold) secure.

If you are not familiar with Single Sign-On systems, it can be a confusing topic. But don't worry - in about 5 minutes you'll have finished reading this article and will be able to talk about SSOs with authority!

I recommend that engineers and non-technical team members both have a shared understanding of terminology and practical steps involved in implementing SSOs, so that everyone is on the same page.

The purpose of an SSO and the problems it solves

Organisations that operate multiple web-based systems - such as websites, mobile applications, CRMs, events management systems, or marketing platforms - often encounter the common issue of having users that need to access multiple systems. This is a problem because each system has its own method of authenticating users and storing their profile information. Challenges are then created for both the organisation's staff and the users themselves as they try to manage multiple sets of login details.

For example:

• Users need to register with, and remember separate login credentials for, each system. 

• If they want to update this information (such as changing their password, email address, or avatar), they must repeat the process for each system. 

• This causes frustration for users and leads to inconsistent levels of security.

What about when an individual leaves the organisation? 

• Their accounts must be promptly blocked or removed from all systems. 

• If each platform manages users independently the risk of human error is increased (e.g. admins forget to disable an account on one or more platforms). 

• This oversight can result in allowing unauthorised access to company systems, which is a critical security risk.

You can see the problem, and these are just two of several situations that could occur. 

The common sense answer is to streamline the number of platforms and login details for each user into one - using an SSO. We can then improve user experience, and ensure better security.

Understanding SSO terminology and the SSO ecosystem

There are specific terms used in the world of SSOs that you should know. Let's take a look at some practical definitions for each term, using real-life examples.

Single Sign-On (SSO) and Federated Identity Management (FIM)

SSOs should not be confused with federated authentication (often referred as Federated Identity Management or FIM), which also provides a single sign-on mechanism, but for different independent organisations.

Here's an example: 

When a person uses their Google Apps account to log into Google Mail or Google Calendar applications, it is an instance of Single Sign-On authentication. Although these applications are functionally independent from each other and exist on separate subdomains, they still belong to the same suite of tools (Google Apps). 

On the other hand, if the same person uses their Google account to log into The New York Times website, this is federated authentication (FIM). 

To understand the difference between these two uses, FIM may be thought of as "SSO for external tools". 

In practice, it means that the level of trust required between SSO and FIM solutions is different, so a different selection of authentication tools and additional checks is needed.

Identity Providers (IdP) and Service Providers (SP)

The tl;dr on IdPs and SPs is this:

• A web application that maintains a database of users for authenticating access to other systems is called an Identity Provider (IdP). 

• A web application that uses an Identity Provider to verify the identities of its users is called a Service Provider (SP). 

In the previous example, Google Apps is being used as an Identity Provider, and The New York Times website is the Service Provider.

More on Identity Providers:

An Identity Provider securely stores authentication credentials (such as user email address and password) to confirm a user's identity accurately. In addition, it may store other relevant user data, such as user names and profile pictures. 

Users exclusively interact with an IdP to update their profile information, which is then automatically synchronised with other Service Providers that employ the same Identity Provider for user authentication. It should be noted that there can be delays in the synchronisation of information between the IdP and the SP, as syncs typically happen when a user logs into their SP.

More on Service Providers:

An important point: Service Providers don't rely on their own authentication mechanism to verify user identities. Instead, they depend entirely on an Identity Provider to validate user identity and provide user information. 

This creates an additional security burden for the Identity Provider, because if the user credentials are stolen, it can give hackers access to all the Service Provider's systems.

Service Providers have the flexibility to use both IdP authentication and their built-in authentication simultaneously. They can even trust multiple Identity Providers to verify users' identities. In this kind of setup, it's crucial for a smooth user experience to link similar user profiles together. 

For example, if a user logs into a website using their email and password, and the next time they use a Google Apps account with the same email, the Service Provider should recognize that it's still the same person and log them into the same account. Otherwise, it gets annoying for the user if the Service Providers creates a new accounts for them.

SAML, OAuth, Open ID Connect (OIDC), LDAP, CAS

Don't panic! I'll explain these names and acronyms without getting into technical details.

Each of the above is an SSO protocol. In a nutshell, an SSO protocol is an agreement between IdP and SP systems on how they should exchange data to understand and trust each other.

What you need to know is that some of them are designed for authentication, some of them for authorisation, and some of them for both. 

Here comes my favorite part - the key difference between authentication and authorisation: 

• Authentication verifies user identities, just like when you take a flight, there’s a check to ensure the person flying is the one named on the ticket. 

• Authorisation verifies user permissions, so if the flight ticket is for economy class, the person taking the flight won’t be allowed to sit in business class.

The key takeaway is this: One of the first things to decide when setting up an SSO is which protocol(s) to use. It's important that all IdP and SP systems support the same protocols. Otherwise, there can be compatibility issues. Systems using different protocols simply won't work together.

Okta, Shibboleth, Auth0, Azure Active Directory, Amazon Cognito, MiniOrange 

More names, I know! Don't worry - I'll explain these tools in simple terms too.

These tools are some of the "as-a-service" solutions that can act as Identity Providers. While there are many other IdPs available on the market, these are the most well-known and frequently searched ones. 

The great thing about these services is that they offer pre-configured IdPs, ready to plug into your Service Providers. They also have strong user authentication systems, user management capabilities, and integrate with many platforms and content management systems (like Drupal or Wordpress).

Remember though, these services aren't free. A good solutions architect will consider your Service Provider requirements as well as the number of users to estimate service costs for you. It's usually about finding the right balance between the speed of initial setup (including importing your user database), desired user experience, and ongoing expenses.

It's worth mentioning that you don't have to use these services if you don't want to. There are plenty of open-source libraries that can turn a web application into an Identity Provider. 

These solutions are usually small standalone libraries that can be integrated into your user databases and authentication flow. 

Turning a web application into an IdP or SP

Let's finish off by seeing what it takes to make Drupal, Wordpress or any other PHP application an Identity or Service Provider. 

Luckily for us, a fantastic open-source library called SimpleSAMLphp can help with this. It supports integrations with all the popular SSO protocols, and if you have a unique solution in mind, there’s an option to create a custom auth protocol as a plugin to the library.

To start using the SimpleSAMLphp library, developers usually install it either on a subdomain (like https://sso.example.com/) or a domain subpath (such as https://example.com/sso/) of a web application, as it needs to be accessed externally by other IdPs or SPs. It can be configured as an IdP, or a SP, or both. 

Additionally, it usually requires a plugin to connect the SimpleSAMLphp library to the web application. For example, for Drupal the plugin is called DrupalAuth.

SimpleSAMLphp comes with its own user login interface for authentication in IdP, but it can also use one provided by your main web application. Using Drupal as an example again - it’s possible to use standard Drupal user login forms to authenticate users into external Service Providers.

Key takeaways on SSOs

As you learn more about SSOs, you'll come across plenty of acronyms, various free and paid services, libraries, and SSO protocols that might initially appear complex, but fear not! Understanding the world of Single Sign-On is easier than it seems. 

It all boils down to these four key elements:

1. Understanding the type of solution you want - SSO or Federated SSO / FIM
2. Defining which service(s) or web application(s) will play an Identity Provider role
3. Defining which service(s) or web application(s) will play a Service Provider role
4. Selecting and implementing SSO protocol(s) supported by both IdP and SP

Still don't want to do it yourself?

Even when you know more about SSOs, if you're not a developer (or even if you are!) you may want to have someone else take care of it for you. That's where we come in. 

SystemSeed have set up and managed new SSOs, or customised existing SSOs, for clients both large and small. We know what we're doing if you need a hand.