Everything we thought we knew about single sign-on (SSO) over the last decade is wrong. Turns out, vendors have manipulated the definition of single sign-on for their benefit. The term started in the last decade as a wide range of new web applications emerged on the scene. The goal was to provide an organization’s employees with a simple way to access all of these applications. Ideally, the credentials used to access these cloud services would be the same credentials that an employee used to access the corporate network.
The Vision and Early Years of Single Sign-On
A decade ago this was possible because there really was only one set of credentials for a network and device. Microsoft infrastructure was practically the only game in town, so organizations would likely have Active Directory and a domain controller. Those would serve as a behind-the-scenes solution to allow one set of credentials access to the network and a user’s device. A class of single sign-on providers, as they came to be known, would integrate with Active Directory and use that identity to extend to cloud applications. If a user visited a website, which was supported and granted the user access, they would effectively be automatically logged into the site. This brilliant vision is how the term single sign-on came to be known. One identity would allow access to just about all corporate IT assets. Great idea, right?
Heterogeneity of Networks and its Impact on SSO
Of course, like anything in IT, this was a short-lived phenomenon. Homogenous Microsoft networks weren’t around for long. With Apple’s resurgence, AWS’s outsourced data center infrastructure, and the utter dominance of Google Apps, an IT organization’s simplistic Microsoft network ceased to exist. The result? An explosion in single sign-on. Active Directory no longer controls a majority of the IT assets. In fact, Microsoft Windows has dipped to account for one out of every five devices over time. Users now have different credentials for their Mac device, Linux servers hosted at AWS, WiFi access, and legacy on-premises applications. A large number of web applications were added into the mix because of the influx of single sign-on apps. This was a far cry from the vision of one identity to rule them all.
Exacerbating the problem was the explosion of authentication protocols coming on to the scene. Each type of IT resource would seemingly use a different protocol. Historic protocols such as LDAP, Kerberos, and RADIUS were now being forced to mix with SAML, OAuth, OpenID, and others, while Active Directory and web application single sign-on were self-supported. Single sign-on became a misnomer very quickly, but vendors kept pushing the term because it was the holy grail of the identity space.
The Future of Single Sign-On
Now, almost a decade after the term started to emerge, true single sign-on appears to be on the horizon. Authentic single sign-on goes to the roots of SSO – when a user could truly use one set of credentials to securely login to whatever IT resources they needed. The fundamental shift took a new wave of innovation in the form of a multi-protocol cloud-based directory service. Known as Directory-as-a-Service, the central user database is focused on providing access to a wide variety of IT solutions by supporting all of the major authentication protocols. As a result, an identity can be converted into the proper format for a particular resource. Web applications that need SAML sit side-by-side with legacy applications that need LDAP or devices that need to leverage RADIUS for WiFi access.
True SSO has required a new generation of problem solving but is needed more than ever. The heterogeneous nature of today’s infrastructure is testing the old school directory and SSO solutions. If you would like to learn more about SSO and how next generation approaches are creating one set of credentials for access to all IT resources, drop us a note. We’d be happy to discuss it with you.