Category: Security

Launch browser. Enter username password. Log in. Done. How hard could it be? This is a challenge I run into when I talk about security and identity. My demos are so boring, because after all that jazz, you see “Hello username” written in Times New Roman. It really punctures the demo, doesn’t it?

As it turns out, authentication can be quite involved. And it’s still evolving every day because this boundary to your application is under duress, constantly, and our enemies are getting smarter. That’s what this article is about. And although I’ll talk generically and stick to general concepts, I’ll use Azure AD as an example.

A Long Time Ago

A long time ago when the internet was nascent, we used a text-based browser called Lynx. There were other mechanisms to access information on the internet too. There was this protocol called SMTP, which is still widely used today. Did you know that SMTP existed basically as an unauthenticated protocol for almost three decades? All it took was understanding the protocol and Telnetting to the SMTP server, and you could send email as anyone. Boy, did I have some fun with that.

I used to wonder, how could this be so simple? I could set up three email addresses, A, B, and C. A forwards to B and C. B forwards to A and C, and C being the email address. Now, I could just initiate an unauthenticated email to A, and C will get overwhelmed by email messages causing old-style DDOS (distributed denial of service), and you know what? It worked. This is how insecure the internet used to be not too long ago. Frankly, with a slight modification, you could defeat inboxes even today.

This is what keeps me up at night. The internet, still, feels very flimsy, and thanks to my unimpressive demos, almost nobody cares about security in a project. It’s all about deadlines and features, and security is just an inconvenience to get past.

A very long time ago, we invented an authentication protocol called basic authentication. This was just sending the username password over the wire in a header. We tried to secure it using HTTPS, but plenty of governments and organizations can sniff HTTPS traffic as a man-in-the-middle. So we came up with NT Lan Manager version 1 (NTLMv1), which was easily defeatable. Followed by NTLMv2, which was better and is still in wide usage today but has plenty of shortcomings. And perhaps the most common legacy protocol in widespread use today is Kerberos. Kerberos relies on a central authority and plenty of network chit chat, so it didn’t scale to the internet.

As these dinosaur protocols roamed the earth, a meteorite called the internet came by to spoil their party. Organizations tried to solve the puzzle by using VPNs and trust relationships between active directories, but you can’t survive a direct hit from a meteorite like the internet. Well, to be precise, some dinosaurs survived. I mean we still have crocs and gators around us, right? Kerberos still has a place on your intranet. But we needed something different, something that focused on the internet.

WS-Fed and SAML

In the early 2000s, the WS-* standards started taking shape. One of these was WS-Fed, and with it came SAML, security assertion markup language. SAML is an XML packet format. In the early 2000s, accessing the internet was either through a website, i.e., a browser on your desktop, or via protocols such as FTP, Telnet, etc. It became clear that websites could offer value if we found a secure way for users to log in.

A post and redirect-based standard emerged, called WS-Fed. At a very high level, it separated the responsibility of the IdP (or identity provider), the entity that performs authentication, and the RP (or relying party), also known as service provider, which is the application you’re trying to access. The RP trusted the IdP and this trust was established using certificates. The idea was that the user lands on the RP, and the RP says, “hey, you aren’t authenticated, so please go here to prove who you are.” The user could optionally be given more than one choice of an IdP. The user goes to the IdP, proves who they are (via credentials such as username password or more), and the IdP sends back a SAML packet with enough information about the user that the RP can use to establish identity and proceed.

This “enough information” is the attributes about the user, also known as claims.

WS-Fed served us well for many years. One of the products that used it was SharePoint. As time progressed, the demands of applications increased. For instance, they expanded who could initiate an authentication. If the RP initiates an authentication…

… this article is continued online. Click here to continue.