Single Sign-On: A Rick the Toolman episode.

I'm a sucker for convenience. Much to the chagrin of my long suffering wife, if there is a choice between spending a few extra bucks to make my life easier or being frugal, for me, personal comfort wins every single time, mostly because I'm shallow, and impatient, and lots of other adjectives that describe an entire set of my own First-World problems. When the movie theater app asks me to apply the two-buck convenience fee, I don’t even blink twice. When the pizza delivery app lets me tip and give instructions to leave that scrumptious pepperoni goodness on the porch without me having to talk to an actual human face-to-face, I gladly put that choice in the “No-Brainer” category. So, when I tell you that I think Single Sign On (SSO) is a first principle security tactic that is handcrafted for people like me, you’ll totally understand where I'm coming from. 

But it turns out that how we do SSO in the real world is complicated and messy, and how we got there is a byzantine maze of innovation and standards that has taken years to evolve. But, if zero trust is the first principle strategy we’re all trying to pursue, getting Identity and Access Management (IAM)  right is the most important first step. After all, you can’t very well restrict access to material resources based on “need-to-know” guidelines from people, devices, and software components unless you know exactly who and what is running around your network. And SSO is a piece of the entire Identity and Access Management puzzle. 

It has the benefit, if done correctly, of making the day-to-day operations of your employees and contractors simpler because they don’t have to keep track of hundreds of passwords just to do their jobs. In that way, SSO is one of the only security tactics that you can sell to management as a return on investment; as a way to make the company run more efficiently. We pursue all the other first-principle strategies and tactics as a way to reduce risk. We do that with SSO too, but it also could improve the way the business operates.

And that’s the reason I'm pulling out the toolbox for this Rick-the-Toolman essay. Identity and access management is essential to our overall first principle program. SSO is a key part of that. Let’s figure out how it works.

What is SSO and where did it come from?

Before SSO (pre-2000s), identity and access management was the handshake process of a user or application sending credentials to a workload in order to gain access. The workload would verify the persona and grant access if the user’s credentials were valid. Users repeated this process for every application and network that they needed access to. That meant that these same users were expected to keep track of many different passwords. Security leadership blamed them if they couldn’t come up with good ones, or used the same ones over and over again. We publicly shame those users in annual reports of the most common and lame passwords used by everybody on the internet; mostly some combination of “12345.” This is essentially victim blaming and faults people for being exceptionally bad at using a stop-gap identity system invented in the early 1960s. That doesn’t seem right.

At a conceptual level, SSO is the idea that a user or application can assert their identity once to a trusted source. When that same user needs access to some workload somewhere, the user directs the workload and the trusted source to work out if the request is valid or not. The good news is that users only have to remember one password. The bad news is that they can still use an easily guessable password like “12345.” Two factor authentication can improve that situation, and we will talk about that in an upcoming essay. But SSO greatly simplifies the identity and access management process although it has taken us 50 years to get here.

As I mentioned, Doctor Fernando Corbato invented the idea of passwords in the early 1960s simply as a stop-gap measure to prevent multiple users on the same mainframe from seeing each other’s files. By the 1970s, computer administrators used Access Control List (ACL) mechanisms to restrict access. In the late 1980s, MIT researchers developed an authentication protocol, Kerberos, designed to work in untrusted networks. In other words, they didn’t send passwords in the clear across the network, they sent asymmetric keys.  In the early 1990s, Steve Kille, and Wengyik Yeong developed LDAP (Lightweight directory access protocol), a protocol that makes it possible for applications to query user information across a network like usernames, passwords, email addresses, anything really. Today, Microsoft’s Active Directory runs LDAP-like services under the hood. 

In the early 2000s, two technologies emerged that would move us closer to SSO: SAML and OAuth. SAML (pronounced “SAM-EL”) stands for Security Assertion Markup Language and refers to a heavy weight XML variant language that facilitates one computer to perform both authentication and authorization on behalf of other computers. OAuth is a competing technology and stands for open authentication. According to CSO Magazine, most network operators use SAML for enterprise applications and OAuth for surfing the net.

Let’s see how they both work.

0auth process.

According to Michael Bissell at NWEA, to make SSO work, three parties are involved: the user (like raceBannon99, internet troll), the identity provider (the authoritative source of some user’s identity and roles, like Google), and the service provider (the application raceBannon99 is trying to get access to, like Twitter.) 

raceBannon99 surfs over to Twitter and begins the process to sign in. Twitter says to go get an asymmetric key from the identity provider (Google). Race then asks Google for a key to let Twitter validate his credentials which Google packages and sends back to him. Race then sends that key over to Twitter. Twitter sends the key to Google and asks, “Hey, is this guy legitimate? Google responds with, “Why yes, raceBannon99 is a fine fellow,” but you know, probably in leetspeak, a language that only computers understand. In this 0auth transaction, none of the three parties exchanged passwords. They simply passed asymmetric keys to each other. 

You can try this yourself. Go to Twitter and sign out (or you can use any web application that you like). Then, try to sign in again. Twitter will present you with a menu of choices. In my case, I have three. I can use Google as the identity provider, Apple, or, I can just send Twitter my username and password. When I push the “Sign in with Google” button, Google asks me which of my three accounts to use for this transaction: my personal email, my work email, or my dumpster diver email (the email I give to web sites when they insist I provide one.) When I select my personal email, I'm magically logged into Twitter using all the steps in the previous paragraph. Excellent!! I didn’t have to remember my password, which I created in 2007 by the way, and SSO made my life easier.

According to Ben Lutkevich at TechTarget, these are some of the more popular companies that offer identity provider services:

• Google
• Facebook
• Apple
• Fitbit
• Microsoft
• Box
• Amazon Web Services (AWS)

SAML Process.

The SAML process is similar to the 0auth process except that the protocol is more robust. What I mean is that, instead of simply sending asymmetric keys around like 0auth, SAML allows the identity provider to package and encrypt user information like PII (Personally Identifiable Information), security groups, roles, and other useful information. We can use this information in establishing our zero trust strategy. It also allows for more verification of each of the entities.

Rick Howard, security executive, surfs over to the internal Cyberwire news wiki (CNW) and begins the process to sign in. Since the Cyberwire is almost entirely a G Suite shop, the CNW tells Rick to retrieve an asymmetric key from the G Suite identity provider. Rick then asks G Suite for the key. Since this protocol is more robust, the G Suite identity provider asks the CNW to verify that it’s legitimate by exchanging asymmetric keys. Once verified, G Suite encrypts a package of Rick’s user information with the CNW key and sends it back to him. Even though it’s Rick PII, Rick can’t get into it because it’s encrypted with the CNW key. Rick then sends the encrypted package over to the CNW. The CNW now opens the package to examine Rick’s PII and can make access decisions based on Rick’s role.

As in 0auth, the SAML identity provider is key and essential and there are many ways to implement it. According to Bissell, here are a few of the common systems that identity and access management programs can use (there are many others).

• Active Directory
• G Suite
• Lightweight Directory Access Protocol (LDAP)
• PingFederate
• SharePoint

SSO in internet years.

SSO has taken a long time in terms of internet years to come close to something that is usable. In terms of normal years though, the transition has been phenomenally fast. What I mean by that is that internet time flies by. We are impatient that it has taken 15 years from the time we got the iPhone (2007) to the time that we could reliably stream “Moon Knight” on it from Disney Plus. That’s internet time. And it feels like it took forever. But, in human years, OMG! It has only taken 15 years in order to stream a world class movie franchise on my phone. That’s amazing. And that’s the same with SSO. From SAML’s inception in 2002 and 0auth’s beginnings in 2010, normal internet users today can take advantage of SSO for every day internet interactions thanks to 0auth. Corporate security people can create a robust zero trust framework with SAML. That will require a little more effort and planning, but the bones are there. SSO is a thing  and we should all be pursuing it with vigor.

Identity and authentication timeline.

1960:

• Fernando Corbató introduces the use of passwords.

1960s - 1970s:

• Computer administrators used Access Control Lists (ACLs) mechanisms to limit access.

1988:

• The Kerberos v4 protocol was first publicly described in a Usenex conference paper. 

1993:

• Tim Howes, Steve Kille, and Wengyik Yeong develop LDAP.

1999:

• Microsoft introduced a product called Microsoft Passport that was soundly rejected by the internet for many reasons but mostly because it was proprietary.

2000:

• Windows Server 2000 released, the first rollout of Microsoft Active Directory using Kerberos.

2002:

• Sarbanes Oxley: Held companies liable for bad access control.
• SAML V1.0 became an OASIS standard.

2005:

• Brad Fitzpatrick develops the first generation OpenID authentication protocol.

2006:

• First managed identity services.

2007:

• The second-generation OpenID specification (OpenID v2.0). 

2010:

• First Identity as a Service in the cloud.
• OAuth was released as an open standard as RFC 5849, and quickly became widely adopted. 

2011:

• OpenID had become an also-ran, and, Wired declared that "The main reason no one uses OpenID is because Facebook Connect does the same thing and does it better. Everyone knows what Facebook is and it's much easier to understand that Facebook is handling your identity than some vague, unrecognized thing called OpenID." (Facebook Connect turned out to not be a world-beater either, but at least people knew what Facebook was.)

2012:

• OAuth 2.0 released; widely criticized for multiple reasons but also widely used.

2014:

• OpenID Connect was released, which reinvented OpenID as an authentication layer for OAuth. 

References.

“Computer password inventor Fernando Corbato dies at 93,” by Jon Fingas, engadget, 13 July 2019.

“Fernando Corbató: American physicist and computer scientist,” by William Hosch, Encyclopædia Britannica, 8 July 2020.

“Here’s 2022’S Worst Passwords — Don’t Use Any of These,” by Paul Wagenseil, Tom’s Guide, 2 March 2022. 

“History of LDAP,” by ldapwiki.com.

“History of SAML,” by saml.xml.org, 2015.

“How Does Kerberos Work? The Authentication Protocol Explained,” by Aaron Katz, freeCodeCamp, 19 July 2021. 

“Identity Provider,” by Ben Lutkevich, SearchSecurity, TechTarget, 2021. 

“Internet Directory Services Using the Lightweight Directory Access Protocol,” by Greg Lavender and Mark Wahl, Sun Microsystems, 2003.

“IPhone History: Every Generation in Timeline Order 2007 – 2022,” by  Matthew Jones, History Cooperative, 14 September 2014. 

“Kerberos and Windows Security: History,” by Robert Broeckelmann, Medium, 16 May 2018.

“LDAP and Kerberos, So Happy Together,” By Juliet Kemp, ServerWatch, 12 January 2009.

“Single Sign-On: What It Is, How It Works, and Why You Need It,” by Sierra Rogers, Capterra, 11 November 2020. 

“The Difference Between LDAP and SAML SSO,” by Zach DeMeyer, JumpCloud, 3 April 2019.

“The Evolution Of IAM (Identity Access Management,)” by SolutionsReview, Youtube, 3 September 2019.

“What Is LDAP & How Does It Work?,” by Okta, 2016. 

“What is OAuth2?” by Tech Primers, 30 June 2017.

“What is OAuth? How the open authorization framework works,” By Roger A. Grimes and Josh Fruhlinger, CSO, 20 September 2019.

“What is OAuth really all about - OAuth tutorial,” by Java Brains, 23 November 2019.

“What Is SAML? | How SAML Authentication Works,” by Cloudflare, 2022. 

“What Is Single Sign-on (SSO)? SSO Benefits and Risks” Jen English, Eye on Tech, YouTube, 10 May 2020.

“What Is SSO,” by Michael Bissell, nwea, YouTube, 2 November 2017.