{"id":3905,"date":"2021-08-20T08:00:00","date_gmt":"2021-08-20T12:00:00","guid":{"rendered":"http:\/\/www.jumpcloud.com\/blog\/?p=3905"},"modified":"2024-11-14T17:33:34","modified_gmt":"2024-11-14T22:33:34","slug":"what-is-single-sign-on-sso","status":"publish","type":"post","link":"https:\/\/jumpcloud.com\/blog\/what-is-single-sign-on-sso","title":{"rendered":"What is Single Sign-On (SSO)?"},"content":{"rendered":"\n
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. <\/p>\n\n\n\n
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. <\/p>\n\n\n\n
To understand the full story of how SSO solutions benefit organizations of all types and sizes and why it\u2019s necessary to implement SSO<\/a> within your tech ecosystem, it\u2019s essential to first understand what single sign-on is and how it has evolved over time.<\/p>\n\n\n\n Single sign-on is the idea that a user only has to log in once to access all of their IT resources; they don\u2019t 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. <\/p>\n\n\n\n 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\u2019s 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. <\/p>\n\n\n\n However, these LDAP-based directories provided the first real method to deliver a \u201csingle sign of experience.\u201d 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.<\/p>\n\n\n\n However, given that AD was hosted on-prem, within the confines of an organization\u2019s 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\u2019s 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n Users have one set of credentials that they can use to login to their Microsoft device and Windows-based resources.<\/p>\nOld definition of SSO<\/cite><\/blockquote>\n\n\n\n While it wasn\u2019t 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 \u2014 these solutions are often referred to as IDaaS or Identity-as-a-Service. <\/p>\n\n\n\n This happened because AD and on-prem domain controllers working behind the scenes weren\u2019t built to handle web applications and anything unrelated to Windows \u2014 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.<\/p>\n\n\n\n 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\u2019s resurgence, AWS\u2019s outsourced data center infrastructure, and the utter dominance of Google apps, an IT organization\u2019s simplistic Microsoft network is becoming a relic of the past. <\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2014 something needed to change drastically. The bottom line: SSO shouldn\u2019t mean a complicated set of group management tools that provide \u201cunified\u201d 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\u2019s not truly SSO.<\/p>\n\n\n\n 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.<\/p>\nNew definition of SSO<\/cite><\/blockquote>\n\n\n\n As modern technology continues to shift and new ideas and processes surface, it\u2019s important that we understand the full breadth of these changes. This means redefining SSO<\/a> 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. <\/p>\n\n\n\n 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.<\/p>\n\n\n\nWhat is SSO?<\/h2>\n\n\n\n
How Single Sign-On Evolved: The Full Story<\/h2>\n\n\n\n
SSOs Past<\/strong><\/h3>\n\n\n\n
\n
<\/figure>\n\n\n\n
The Future<\/strong> of Single Sign On<\/h3>\n\n\n\n
\n