By Vince Lujan Posted August 24, 2017
In theory, Single Sign-On (SSO) should describe exactly what the name implies – the ability to leverage a single set of credentials to sign-on to various resources. Yet, the modern understanding has come to describe different things depending on who you’re talking to. For most people today, it means one set of credentials for access to web applications.
However, if that means separate credentials for on-prem resources like legacy applications, systems, networks, cloud infrastructure (e.g. AWS, GCP, Azure AD), or even your core user identity, can it really be considered True Single Sign-On™? Understanding the origin of the idea is important for understanding what True SSO is, but perhaps more importantly, what it isn’t.
SSO in the Beginning
SSO was borne at a time when Microsoft ruled the IT world. It was a time when just about everything was on-prem: users had to be physically present at their desks, systems were hardwired into private networks, applications were primarily Windows-based and came in a box with installation disks. The implementation of web applications was miniscule, and admins knew they could rely on Active Directory® for identity and access management (IAM) over their domain.
Around the turn of the century, many application vendors began to shift their delivery away from out of box solutions in favor of the cloud. Applications like Salesforce led the way and were very successful, leading many others to follow suit. The trouble was these new Software-as-a-Service (SaaS) apps lived outside of the AD domain. Thus, additional management solutions were required to control them.
This opened the door for a wide variety of “so called SSO” solutions aimed at extending AD credentials for access to these types of resources, namely web applications. The idea was that by extending AD, users could then leverage one set of credentials to gain access to on-prem resources and web applications, admins could retain control over user access and management beyond what was possible with AD alone – and everybody wins.
It seemed like SSO and AD were a perfect match. However, nothing is constant in the IT world. Before long, this relationship began to break down. Mac and Linux systems began to make their way into the enterprise with their own set of solutions for management, wired network connections were replaced with WiFi, servers were hosted at AWS and other IaaS providers, and there was a general push towards a new cloud-forward model. In order to be secure, all of these resources required authentication for access. This meant that Active Directory, which was and has always been designed for managing on-prem Windows resources, wasn’t as effective. As a result, the SSO providers that were built on top of AD suffered the same fate.
Today, SSO providers are having somewhat of an identity crisis. Users still want one set of credentials for access, but for much more than just web apps (e.g. remote systems, devices, WiFi, cloud or on-prem servers). Admins want the ability to flip a switch to authorize access for everything. Unfortunately, traditional SSO providers cannot fit the bill. Yet, with so many resources available these days, is it even possible to have a True SSO™ solution?
The Future of SSO
Directory-as-a-Service® has taken a new approach to single sign-on. Instead of layering your SSO solution for access to cloud apps on top of your on-prem directory service, what we’ve done is move the entire directory service to the cloud and expanded the viewpoint of what a cloud identity management platform should do.
The result is that users can leverage one cloud identity to gain access to all of their applications, both on-prem and in the cloud. It’s not only web applications either. Directory-as-a-Service leverages a wide variety of protocols, including SAML, LDAP, SSH, RADIUS, and REST across all of your IT resources such as system endpoints (e.g. Windows, Mac, Linux). What that means for admins is that none of their resources are out of the reach of the first comprehensive cloud based solution for centralized identity management. In essence, Directory-as-a-Service is to cloud infrastructure what AD was to on-prem. The core difference being that with Directory-as-a-Service, the entire world is your domain.
If you would like to know more about what True Single Sign-On is, or how Directory-as-a-Service can benefit your organization, drop us a note. You can also sign-up for a free cloud directory account and see for yourself. Your first ten users are free forever.