CSO Perspectives (Pro) 5.9.22
Ep 76 | 5.9.22

Single Sign-On: A Rick the Toolman episode.


Rick Howard: I'm a sucker for convenience. Much to the chagrin of my long-suffering wife, if there's 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.


Tim Allen: (As Tim Taylor) Oh, yeah. 

Rick Howard: So when I tell you that I think that single sign-on, or SSO, is a first-principle security tactic that is hand-crafted 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 us years to evolve. 


Tim Allen: (As Tim Taylor) Oh, no. 

Rick Howard: But if zero trust is the first-principle strategy we're all trying to pursue, getting identity and access management 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 added 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. 

Rick Howard: We pursue all the other first principles, 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 episode. Identity and Access management is essential to our overall first-principle program. SSO is a key part of that, so let's figure out how it works. 

Rick Howard: My name is Rick Howard, and I'm broadcasting from the CyberWire's secret sanctum sanctorum studios, located underwater somewhere along the Patapsco River near Baltimore Harbor. And you're listening to "CSO Perspectives," my podcast about the ideas, strategies and technologies that senior security executives wrestle with on a daily basis. 

Rick Howard: Before we had 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 they needed to access. 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 what was essentially a stopgap identity system invented in the early 1960s. That doesn't seem right. 


Tim Allen: (As Tim Taylor) Oh, no. 

Rick Howard: At a conceptual level, SSO is the idea that a user or application can assert their identity once to a trusted source. When the 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'll talk about that in an upcoming episode, but SSO greatly simplifies the identity and access management process, although it has taken us 50 years to get there. 

Rick Howard: As I mentioned, Dr. Fernando Corbato - Corbi to his friends and colleagues and winner of the A.M. Turing Award in 1990, widely considered by many to be the computing field's equivalent of the Nobel Prize - also invented the idea of passwords in the early 1960s simply as a stopgap measure to prevent multiple users on the same mainframe from seeing each other's files. By the 1970s, computer administrators used access control list mechanisms, ACLs, to limit access. In the late 1980s, MIT researchers developed an authentication protocol, Kerberos, designed to work in untrusted networks. In other words, Kerberos didn't send passwords in the clear across the network. It instead sent asymmetric keys. 

Rick Howard: In the early 1990, Steve Kille and Wengyik Yeong developed LDAP, Lightweight Directory Access Protocol, a method to make it possible for applications to query user information across a network - things like, you know, usernames, passwords, email addresses, anything, really. Today, Microsoft's Active Directory runs an LDAP-like service under the hood, but in the early 2000s, two technologies emerged that would move us closer to SSO - SAML and OAuth. SAML stands for Security Assertion Markup Language and refers to a heavyweight XML-variant framework 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. Now, according to CSO magazine, most network operators use SAML for enterprise applications and OAuth for surfing the net. Let's see how both of those work. 

Rick Howard: According to Michael Bissell at NWEA, to make SSO work, three parties are involved - the user, like me, username raceBannon99, an infamous internet troll; the identity provider, the authoritative source of some users' 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. In the OAuth process, Twitter says, hey, raceBannon99, go get me an asymmetric key from the identity provider - in your case, 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 the key over to Twitter. Twitter, on receipt, sends the key to Google and asks, hey, Google, 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 OAuth transaction, none of the three parties exchanged passwords except for the first time that raceBannon logged into Google. They simply passed asymmetric keys to each other. And once initiated, it's all done without any humans getting in the way. 

Rick Howard: You can try this yourself. Go to Twitter and sign out - or you can use most 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, which I don't want to do. When I pushed 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 - you know, the email I give to websites when they insist I provide one. When I select my personal email, I'm magically logged into Twitter using all the steps I just described. And not to put too fine a point on this but I didn't have to remember my old password... 


Tim Allen: (As Tim Taylor) Oh, yeah (laughter). 

Rick Howard: ...Which, by the way, I created in 2007, and I don't think I've changed since then. Shh - don't tell the CyberWire CSO. He might not approve. Now, according to Ben Lutkevich at TechTarget, some of the more popular companies that offer identity provider services are Google, Facebook, Apple, Fitbit, Microsoft, Box and Amazon Web Services, or AWS. 

Rick Howard: The SAML process is similar to the OAuth process, except that the protocol is more robust. What I mean is that instead of simply sending asymmetric keys around like OAuth, SAML allows the identity provider to package and encrypt user information, like PII - personally identifiable information - or security groups, roles and other useful information. This is one of the first steps in establishing our zero-trust strategy. This is how you're going to pass this information around to see which employees, contractors and software components get access to material resources in your organization. It also allows for more verification of each of the three entities. 

Rick Howard: Rick Howard, security executive, surfs over to the internal CyberWire news wiki, called 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 with each other. 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's 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 now can make access decisions based on Rick's role. As in OAuth, this is all done without human intervention. 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, though. They use Active Directory, G Suite, LDAP, PingFederate and SharePoint. 

Rick Howard: 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+. That's internet time, and it feels like it took forever. But in human years - oh, my God - it has only taken 15 years in order to stream a world-class movie franchise on my phone. That's amazing. 


Tim Allen: (As Tim Taylor) Oh, yeah. 

Rick Howard: And that's the same with SSO. From SAML's inception in 2002 and OAuth's beginnings in 2010, normal internet users can take advantage of SSO for everyday internet transactions thanks to OAuth. Corporate security people can create a robust zero-trust framework with SAML. That will require a little more effort in planning to deploy a robust zero-trust program, but the bones are there. SSO is a thing, and we should all be pursuing it with vigor. 

Rick Howard: And that's a wrap. One last thing - I wrote a companion essay for this show, as I do for all the shows, but at the end of this one is a small timeline of SSO history and evolution. Check it out if you're so inclined. And next week, I will be doing another Rick the Toolman episode, this time on SSO's big sister, two-factor authentication. You don't want to miss that. 

Rick Howard: As always, if you have thoughts about this week's show, or any thoughts in general, send them to CSOP@thecyberwire.com. That's CSOP, the at sign, thecyberwire - all one word - .com. 

Rick Howard: The CyberWire's "CSO Perspectives" is edited by John Petrik and executive produced by Peter Kilpe. Our theme song is by Blue Dot Sessions, remixed by the insanely talented Elliott Peltzman, who also does the show's mixing, sound design and original score. And I am Rick Howard. Thanks for listening.