What is Single Sign-On (SSO)?

Many people seem to think they know what Single Sign-On (SSO) is and assume it is a software add-on that allows users to automatically sign in to all of their core applications by asking for a password only once. Others think it’s an option that you can turn on and off within applications so you can connect as a user on other applications. And still, others think it is a way to control access to applications and what users can do.

Sadly, SSO is not clearly understood even by seasoned information technology experts, and the topic isn’t made any simpler by the marketing efforts of some software vendors that claim to be SSO-compatible.

Hopefully, this post will shed some light on what SSO really is and what it is not. I will attempt to minimize complexity whenever possible—but be forewarned that SSO is not for the faint of heart. It is a complex subject to begin with, and it is hardly standardized by the software industry. It is only made more obscure by those who do not fully understand it and those who make a living off of its complexity. Plus, it can be very difficult to understand and even harder to implement.

SSO is a Concept

First, it’s important to understand that SSO is a concept, not a technology, a process, or a standard. The SSO concept is that a computer user needs to sign into a device only once and after that, no additional login and passwords will be asked of that user.

The idea of a user flowing across applications is not generally an issue if made by the same vendor. It’s just when you attempt to have more than one software vendor agree on how that should be done that things get messy very quickly.

Let’s take an example. A company is using Microsoft Windows on all of its computers, and all of the company’s employees have a user login and a password to access the internal network. This is managed by the internal IT administrators who most likely use a security directory or database to track everyone’s access and login credentials. On a Microsoft network, they are probably using Active Directory (AD), a Microsoft feature that an IT administrator implements and configures.

While there are other centralized user directories, AD is one of the most widely used for internal networks, especially when an organization is running on Microsoft Windows.

Now the company also has an email service. Initially, they are set up with Microsoft Outlook, another Microsoft application. The idea is that once the user logs into Windows on their laptop, there should be no need for them to log in once more into Outlook to use their email. Windows should “pass” the credentials and identify itself to Outlook, saving the user some time.

This is the basic concept of SSO.

But it gets a little more challenging when the company wants to use another application that is not by the same vendor. Will Windows know how to “pass” credentials to the other application? Are they talking the same language (protocol)? How can Windows know to trust the application to just pass user credentials like that?

Those are some of the issues around SSO when you start going outside Windows-only applications.

SSO on the Web

Now imagine that the company was using Gmail instead of Outlook as its email app. Users login to their laptop and then load their favorite browser and access their Gmail account—at which point they are asked for another set of credentials.

Then they load Salesforce for CRM purposes, and they are asked again for another set of credentials—different from both Gmail and Windows.

Is it possible to configure these applications to use a single, centralized user database?

To answer that, remember that the company already has a user database, but it’s deep in the server rooms of the company, and not typically accessible from outside of the network.

Back in the days before the cloud, privacy services such as VPNs and proxies were put in place to expose the database to some degree and be able to validate outside users.

Today, other services such as Active Directory Federation Services (ADFS) can do both user validation and maintain a database of all user credentials, and also being accessible from the outside. As the cloud movement got underway, many software vendors started their own user databases and offered them as an alternative to Microsoft’s Active Directory.

Today we can sign on to several applications with credentials from our Facebook, Google, Salesforce, LinkedIn, or many other accounts, both personal and business, and share access across them. These systems have become identity providers (IDP) and allow other systems to request to identify you in order to use them. Along with ADFS, these systems are known as Federated Identity Providers. There are also systems, such as OneLogin and Okta, whose sole purpose is to store user credentials in one centralized database and control access to other applications and systems from that one centralized location.

While these apps clearly facilitate the process and save us time, they also increase the security risk. If your access is compromised on one of the above systems, then access to all the systems connected to that IDP is also given immediately. On the other hand, in case of a compromise, or if password rules—for example, forcing password change every 60 days—are enforced, security across all connected systems is much stronger than having to come up with individual passwords for each.

The Difference Between Authentication and Authorization

While Microsoft Active Directory is used to track users and their credentials, it does a lot more than just that. In addition to just keeping your login name, email, and password, it is able to determine what systems you can or cannot access and what functionality you can or cannot use in each system.

This is the difference between authentication, the process by which a database determines if a user is who they claim to be when they request access, and authorization, the process by which the database provides a list of the capabilities, functionality, and permissions that the user is allowed to perform or use in a particular system.

For example, when I try to login to an application, the login page will use the combination of my username and password (and potentially other factors, such as 2 Factor Authentication) to assess my credentials—and either let me in or not.

Once I pass the tests, and I am in, what I am allowed (authorized) to do is a different matter. It’s typically up to each application to determine permissions once a user is logged in. However, with some advanced identity providers such as Active Directory, those same permissions can be centrally managed as well.

Connecting to An Identity Provider

So let’s say that you’re convinced that centralizing identities (users and their security) is a good idea for your organization. You are tired of having to go into each system and create profiles, set up their passwords, reset their passwords, etc.

How do you connect your disparate systems to an identity provider? Well, it’s not easy. First, the systems that you want to connect must be capable of connecting to an IDP, and that capability must also be compatible with your IDP.

Then, as with everything technological, there are more issues around compatibility than just about anywhere else. In the case of SSO, the goal is to set up connections so that whenever a user accesses your application, that application must first contact the IDP with some code to determine if you are already logged in on that device.

If you are not logged in, then the application must redirect to the login page of the IDP so that you can get logged in for the first time.

And—it must do all this in a secure way that avoids hackers sneaking in, impersonating the user who’s attempting to login, and intercepting all this back and forth.

Finally, both systems must understand each other and use a common language. There are a few such languages, but the most widely used one is Security Assertion Markup Language (SAML). Essentially, SAML is a file that uses an XML structure to identify who you are, who it is, your URL address, where the certificate is that tells it that you are who you say you are, and so forth.

When taking the plunge into the SSO configuration, you’ll also come across different protocols for enabling secure identity verification. Particularly important is comparing OAuth with JWT, both popular in securing API services. They differ significantly; while OAuth is a delegation protocol allowing access without revealing user credentials, JWT (JSON Web Tokens) facilitates token-based authentication and qualifies detailed claims about an authenticated entity within its structure.

When the IDP and the desired application exchange information, in order to try to send the data (i.e., tokens that represent the user) back and forth to each other or redirect users to the right pages, they will initiate a protocol to attempt to ensure they are talking to the right application without opening the door for third parties snoop around.

If all goes well and the configuration is set, then the IDP will send back to the application all the information it has about that user, such as email, preferences, permissions, and anything else the administrator has configured in the IDP that should be shared with the service provider application.

It is recommended that you purchase or generate a security certificate (SSL Certificate) for both systems. This is important to prove that both systems are communicating with each other and no third-party system is attempting to intercept the communication.

While the configuration process is initially complicated, with a little help from the application provider and IDP, and with some light reading, it can be done.

What About Logging Off?

The topic of logging off is often forgotten, yet it represents a very important part of the process. You have to remember that once you log in to an application that’s connected to an IDP, you are also logged in to the central database—the IDP. Any other application that is also connected will not ask you for credentials since you are already signed in. Hence, the word “single” in “Single Sign-On.”

So, when a user closes their application, are they signed off? What if, in the meantime, they opened another application? Will it kick them out of both applications?

These are the complexities and decisions that each software vendor must wade through and make. Essentially, if a software provider has SSO capability, they should also have Single Log Out (SLO) capability. That means that if a user signs off one application and goes for lunch, then, for the sake of security, they will be logged out of the other applications, otherwise, someone can come in and just simply take over.

But not everyone agrees on this process. Some applications do it while others simply log you out of the current one—only to be accessible immediately since you remain centrally logged in.

As with many things computer-related, the key issue is one of the vendor agreements to follow standards.

Summary

If you’ve done the configuration correctly, then you should now be able to enjoy the ability to centrally manage all of your users without having to access each application individually. Your users will also enjoy the fact that they don’t have to log in to every single system each day or each time they want to access the application.

Compatibility between systems is not guaranteed, so you need to pick the right set of applications and the appropriate identity provider. It is far from simple, and it is regarded as one of the most complex tasks a systems administrator needs to do since it depends on multiple vendors and their individual capabilities. However, once configured correctly, it should work without having to invest a whole lot of time maintaining it in the future.