Share This Article
Single sign-on (SSO) solutions have been gaining traction in the market since the early 2000s when web-based applications started to populate the workspace and users needed an efficient, secure way to authenticate to them.
Fast forward past the COVID-19 pandemic, to the subsequent rise in the necessity (and eventual popularity) of remote and hybrid work environments, which created an even faster adoption of web-based applications and pushed the adoption of SSO even further, as some of the main benefits that SSO provides are improved security, compliance, and productivity for in-office and remote users alike.
To understand the full story of how SSO solutions benefit organizations of all types and sizes and why it’s necessary to implement SSO within your tech ecosystem, it’s essential to first understand what single sign-on is and how it has evolved over time.
What is SSO?
Single sign-on is the idea that a user only has to log in once to access all of their IT resources; they don’t have to type their username and password in over and over, or use multiple, distinct username and password pairs, to get access to everything they need to be successful at work.
Traditional SSO solutions as we generally know them today were meant to bridge the gap between users and web applications back when Microsoft Active Directory (or a similar corollary like OpenLDAP, Red Hat’s Directory 389 or others) was the most common central identity provider (IdP) out there, and physical domain controllers were found in every office to support it.
However, these LDAP-based directories provided the first real method to deliver a “single sign of experience.” In the case of Active Directory (AD), by far the most popular, a user could log in to their Windows device while it was connected to the network, and those credentials would be authenticated via the domain controller. A successful login would result in the user being able to move between Windows resources within the domain without having to log in multiple times as determined by the permissions granted to that user. This eliminated the need for users to remember a variety of passwords in order to access multiple on-prem, Windows-based resources.
However, given that AD was hosted on-prem, within the confines of an organization’s network, it could not facilitate authorization to resources that lived outside of the domain. As such, the growing number of web-based applications that grew in popularity throughout the 2000’s posed challenges to IT admins trying to control and deliver access to them in a similar, secure fashion. So the definition of SSO changed over time as AD and on-prem infrastructure failed to support access to web applications and other non-Windows-based resources that many users needed quick and secure access to.
Now, as the cloud grows even more pervasive, powerful and secure, SSO is often implemented as part of a larger identity access management (IAM) solution, such as a directory service, rather than as a separate add-on, which gives IT admins more control and visibility into what users have access to. SSO solutions that fit into this mold provide users with access to virtually all of their IT resources (networks, devices, apps, file servers, and more) through a single login.
How Single Sign-On Evolved: The Full Story
SSOs Past
Users have one set of credentials that they can use to login to their Microsoft device and Windows-based resources.
Old definition of SSO
While it wasn’t called SSO in the early days, Microsoft created AD which allowed users to simply log in to their Windows devices and subsequently be able to access anything on their network that was Windows-based. However, as web applications emerged in the early 2000s, another generation of SSO solutions emerged to help users authenticate to non-Windows-based resources — these solutions are often referred to as IDaaS or Identity-as-a-Service.
This happened because AD and on-prem domain controllers working behind the scenes weren’t built to handle web applications and anything unrelated to Windows — so organizations utilizing AD had to adopt an external single sign-on provider to close this gap. However, this approach had a few shortcomings. One flaw was that it was still an on-prem solution. In order to work effectively, this version of SSO still required an identity provider like AD. A second flaw to this single sign-on approach was that it only simplified access to web-based apps. Users still needed a separate identity to access their system, networks, and data.
Plus, homogenous Microsoft IT environments became less common, and AD was no longer the single source of truth when it came to employee accounts. With Apple’s resurgence, AWS’s outsourced data center infrastructure, and the utter dominance of Google apps, an IT organization’s simplistic Microsoft network is becoming a relic of the past.
The need for single sign-on deepened as users started accumulating different credentials to sign into resources such as their Mac device, Linux servers hosted at AWS, WiFi networks, cloud applications, and legacy on-prem applications. Manual user management for web-based applications was an option at this point, but users got bogged down with hundreds of credentials. Meanwhile, IT admins had to find ways to face this control and security nightmare.
The old definition of SSO could not handle what was happening in the tech world, and amidst all of these changes, traditional SSO was rendered meaningless — something needed to change drastically. The bottom line: SSO shouldn’t mean a complicated set of group management tools that provide “unified” access to siloed groups of IT resources. Unless you have a single set of credentials used to log in once in order to access your systems, files, networks, and apps, then it’s not truly SSO.
The Future of Single Sign On
Users have one set of credentials that they use to log in to a combined directory and SSO interface which then utilizes different built-in protocols to automatically log them into virtually all of their IT resources including Mac, Linux, and Windows devices.
New definition of SSO
As modern technology continues to shift and new ideas and processes surface, it’s important that we understand the full breadth of these changes. This means redefining SSO in a way that suits modern IT environments and admins alike. Now that there are all-encompassing cloud directory solutions out there, rather than just traditional on-prem directory services like AD, and users need to securely connect to more resources than just web applications, SSO has morphed over time to keep up with this changing landscape.
The only on-prem equipment left in many offices today are WiFi access points (WAP) and end-user devices. For the most part, servers and applications have shifted to the cloud, and corporate data centers are no longer the norm as Infrastructure-as-a-Service providers such as AWS and Google Compute Engine are the dominant solutions. Web applications are the new norm with just about every function within an organization being supported through cloud-based SaaS platforms.
In short, modern SSO has been redefined in a way that supports connections to a myriad of legacy and cloud apps (a few common examples include OpenVPN, MySQL, GitHub, Slack, and Salesforce), a variety of device types (Mac, Windows, and Linux), WiFi and VPN networks, physical and virtual file servers (Samba, NAS, Google Drive, and Box), and any other relevant resources — all from anywhere in the world.
Traditional SSO is not enough anymore, and many organizations have moved on from the idea of an on-prem directory service combined with web SSO to a modern cloud-based directory service that does all of this and more. In a complete access management system such as this, the cloud directory service provides a central user database that’s focused on providing secure access to a wide variety of IT resources by supporting all of the major authentication protocols including LDAP, SAML, SSH, RADIUS, and REST.
As a result, a user identity can be converted into the proper format for a particular resource, no matter what operating system is being used. We refer to this modern solution as True SSO that goes back to the roots of single sign-on – allowing users to provide one set of credentials to securely log in to whatever IT resources they need (not just web applications!).
How Does SSO Work?
An SSO solution must be integrated into your existing directory service infrastructure — usually using the LDAP protocol. Then, it typically uses a standard protocol like SAML to exchange authentication and authorization information between the IdP and web-based applications (or service provider (SP) in SAML parlance).
Other protocols like OIDC are also becoming more widely used as well. In short, the process results in SSO authentication of a user to all of their IT resources through a single login.
SAML and Single Sign-On
The Security Assertion Markup Language (SAML) protocol is the go-to approach for many web application SSO providers, especially for those focused on web applications. SAML utilizes Extensible Markup Language (XML) certificates to assert user authentications between an IdP and an SP or web application. A benefit of this is that end-users do not need to remember different passwords for each web application they use.
This means that users only need a single set of credentials to access their applications – the same core credentials used by their IdP. With a single sign-on system in place, users can create a single, strong password to secure their IdP credentials and access a multitude of IT resources. This solution results in a better experience for IT admins because there’s a reduction in password-related help desk tickets and there’s less worry around the thought of one of a user’s many passwords being compromised.
Most modern SSO providers have a web portal that users log into where they can then quickly access connected applications from one centralized interface, all due to the use of SAML. This leads to an improved end-user experience all while making IT administrators’ lives easier.
On top of that, for web applications that leverage SAML as the authentication protocol, there is a good chance that their security has been stepped up. In general, SAML integration works on assertion rather than a username and password concept. That assertion is being made by the IdP to the SP (in this case the web application). The IdP ensures that the user is who they say they are, and the SP relies on that. The stronger that an IdP can make the authentication process, the better it is. For example, adding multi-factor authentication adds a layer of security to the authentication process and protects resources from bad actors.
Though SAML itself is not a single sign-on solution, it does play an important role within a larger SSO solution. Modern SSO solutions use an array of other protocols and authentication methods to extend one set of user credentials to virtually all resources — one of which is LDAP.
SSO and LDAP
The Lightweight Directory Access Protocol (LDAP) is one of the oldest user authentication protocols in use today for computer systems. It was created in 1993 by Tim Howes and his colleagues at the University of Michigan and was designed to connect users to systems throughout the university back in the early days of the internet. LDAP ended up working so well that it inspired two directory services: AD and OpenLDAP. The main use of LDAP today is to authenticate the users stored in an IdP to on-prem applications.
Now, cloud-hosted LDAP is popular because it provides organizations with all of the capabilities and benefits of the LDAP protocol with none of the traditional setup, maintenance, or failover requirements. Its flexible schema makes LDAP perfect for storing a wide variety of user attributes and permissions, which is basically the core of IAM. Now, modern SSO solutions utilize a variety of authentication protocols, and Cloud LDAP is still one of the most widely used.
You look at the world moving more and more to the cloud, but there’s still a world left behind in your local environment – you’ve got devices, you’ve got printers, you’ve got everything. People also need to be authenticated in these different contexts.
Click here to read more about the differences between SSO and LDAP.
SSO as Part of a Bigger Solution
If you are solely using web-based applications in your environment, you might be able to get by with just using a standalone web app SSO solution. However, the majority of organizations out there also need access to infrastructure (whether cloud-hosted or on-prem), file storage, and internal, protected networks to accomplish their daily work.
Since a single sign-on platform focuses centrally on web-based applications, you need a directory service if you hope to centralize user access to the rest of your IT network. Rather than utilizing an on-prem directory service and adding an SSO solution on top of it, it’s far more cost-effective and easier to manage an IAM solution that includes SSO capabilities all within one platform.
Why Use SSO?
So, now the main question is, ‘why should my organization use SSO?’. The main benefit organizations experience is providing end-users with one set of credentials to access all of their IT resources. We mentioned earlier that SSO dramatically improves productivity, security, compliance, and user experience — but how?
With modern SSO, end-users don’t have to waste half an hour each month just getting access to their online tools, and IT admins only have to spend minutes each week on managing user access to IT resources instead of hours.
When it comes to security and compliance, in a full IAM solution that includes SSO, IT admins can centrally enforce password requirements, multi-factor authentication and conditional access across all of the IT resources used in their organization, and they can know for certain that only the right people have access to critical company resources. The ability to easily manage least privilege access across an organization is a huge win in the security and compliance realms.
Implementing an SSO solution comes with a wide variety of benefits, especially as part of a bigger cloud-based directory service, which is why so many organizations are adopting it.
The Pros and Cons of SSO
Depending on your organization’s needs and the type of SSO solution you choose (directory integrated or add-on), you will realize some advantages and disadvantages to single sign-on. Though the benefits vastly outweigh any potential drawbacks, it’s important to keep all of the information in mind when making a decision.
Pros of SSO:
- Simplifies password management
- Streamlines onboarding/offboarding
- Increases admin control
- Simplifies and streamlines user experience
- Improves security and compliance/reduction in attack surfaces
- Reduces password fatigue
- Decreases help desk requests
- Increases employee and IT productivity
- Prevents shadow IT
- Increases software adoption rates
- Lowers IT costs
Cons of SSO:
- Costly/best at scale
- Requires an IdP to reach its full potential
- Requires extra-strong passwords
- If an SSO provider is hacked, all connected resources are compromised
- SSO requires implementation and configuration
- Shared devices present a problem
Luckily, many of the cons of SSO can be avoided or reduced by leveraging a larger IAM solution that includes SSO and implementing and enforcing specific policies for employees to follow.
Alternatives to Single Sign-On
The term single sign-on means something different to everyone, not only because of its history and how the meaning of the term has changed over time but also because some solutions are marketed as SSO when they really don’t meet all of the criteria to be modern, True Single-Sign On. A couple of popular comparisons are AD and its various add-ons, as well as OpenLDAP.
SSO vs Active Directory
In the early 2000s, given AD’s continued struggles with resources outside of the domain, a handful of third-party vendors created solutions to help extend AD identities to cloud-based and/or non-Windows resources. Coincidentally, the original web application single sign-on solutions hit the market at almost the exact same time that Microsoft added another solution to its list of AD add-ons, called Active Directory Federation Services (AD FS). AD FS uses limited support of the SAML 2.0 protocol to connect an AD identity to a web application which widens the boundaries of the domain to include some web apps.
When it comes to deciding if you want SSO or Active Directory, it’s important to note that they are very different; one is a cloud-based, web app identity extension point solution, the other an on-prem directory service. However, AD FS and SSO are quite similar — both solutions federate on-prem identities to cloud applications, filling a great need in modern identity management.
This solution still does not suit modern IT environments as many organizations use Mac and Linux systems among many other non-Windows-based resources. AD and ADFS still require other solutions to be implemented in order for users to authenticate to everything they need in today’s work environment. Utilizing multiple solutions for a directory service and SSO isn’t ideal, so the market has been shifting towards holistic directory and SSO solutions that offer both within one platform. IT admins already have more than enough on their plates, so the more control they can have from one central place, the better.
SSO vs OpenLDAP
Another solution that is sometimes thought of as an SSO alternative is called OpenLDAP, which is a free, open-source implementation of LDAP that thrives with Linux-based systems. While Microsoft became the main commercial option, OpenLDAP went on to become the open source directory services leader. OpenLDAP is incredibly flexible and is often favored by the ops crowd because of that. However, OpenLDAP also requires deep technical knowledge to work with, which takes it out of the running for many organizations that don’t have the resources to invest in admins that are highly trained in this specific area.
The other trouble with both OpenLDAP and AD is that they don’t easily connect with all of the IT resources that they need to mesh with — if an IT resource doesn’t play well with LDAP or you’re working with a Windows or Mac machine, OpenLDAP isn’t an ideal solution.
If an organization only leverages the LDAP protocol for authentication, then a solution like OpenLDAP might be the only IAM platform required. However, if an organization does not solely use LDAP, then OpenLDAP is not a great solution to implement. In a more heterogeneous IT environment, adopting a broader IdP and SSO solution, that supports both LDAP and SAML at the very least, would be a better choice.
Single Sign-On Solutions
While a standalone SSO solution can be a powerful addition to your IT network, it’s not usually the best solution for modern organizations. Now that IT environments leverage Mac and Linux systems, cloud infrastructure (eg., AWS, GCP, Azure), virtual and physical file storage, and wireless networks, a better solution exists — a directory service with SSO capabilities.
Even if your organization is primarily Microsoft-based and you use any of the other tools listed above, you’ll end up needing more than just AD and web application SSO to gain full control over your environment. You’ll also need add-ons like identity bridges, MDM solutions, VPNs, and more. Not only is this expensive, but the benefits you experience with an SSO solution are diminished. End-users still end up with multiple credentials, which increases the amount of time they have to spend just logging in to their IT resources and provides bad actors with more opportunities to damage your system. IT admins on the other hand are stuck with a piecemeal identity management approach that is cumbersome to manage.
You will be able to better identify appropriate SSO solutions once you’ve laid out the needs specific to your organization’s IT environment. There are different solutions out there that are better suited for some use cases than others — they all usually refer to themselves as SSO providers, or at a minimum consider themselves to be part of that ecosystem.
The Most Popular Types of SSO and SSO-Adjacent Solutions:
- Cloud Directory Platforms – A core user directory solves the SSO problem among many other things. Examples: JumpCloud® and Microsoft
- Web App Single Sign-On – These are SSO add-on point solutions that are only meant to authenticate to web apps. Examples: Okta, OneLogin, and Ping Identity
- Password Managers – These are not necessarily full SSO solutions, but an SSO password manager does allow you to log in to various resources quickly once you’re logged into the manager. Examples: LastPass and Keeper
What to Consider When Buying SSO
All of these SSO solutions exist either layered on top of or integrated with an organization’s core directory or IdP, and they introduce efficiencies not only for admins but also for end-users. Finding the right SSO provider is essential to a healthy bottom-line, improved employee productivity, and secured company resources.
Although each organization’s unique environment ultimately dictates the best SSO solution, here are some other factors to consider when evaluating your options:
- Authentication via SAML
- Pre-built and custom connections to SAML apps
- Authentication via LDAP
- Group-based control
- Multi-factor authentication
- JIT and SCIM provisioning
- Pricing and testing
SSO is perhaps one of the most misunderstood categories in IAM, because it means something different to everybody. Use this breakdown to assess your organization’s needs and choose a solution that will provide the most value for your IT team and end-users.
Adopting True Single Sign-On
The goal of True Single Sign-On is to provide users with a single, secure set of credentials that they can leverage to gain access to virtually any IT resource — without anything on-prem and without multiple point solutions. In doing so, admins can quickly connect users to IT resources from the cloud while improving security and the end-user’s overall experience.
JumpCloud is a next generation IdP that securely connects users to virtually all of their IT resources regardless of protocol, platform, provider, or location. This includes the following:
- Systems: Windows, Mac, and Linux
- Servers: Windows, Linux, GCP, AWS
- Applications: Google Workspace, Office 365, Salesforce, Jenkins, Atlassian, Kubernetes, and more
- File Storage: Dropbox, Google Drive, NAS appliances, and more
- Networks: wired and wireless
By managing all of the above in JumpCloud, you can give your end-users a True Single Sign-on experience, aka — the ability to use a single identity to connect to everything they need to Make Work Happen™, not just web-based applications. Use this comprehensive directory and SSO solution to improve productivity and security, streamline user and device management, achieve compliance, and much more. Sign up for a free trial of JumpCloud to test out the full functionality of the platform before committing.
