The way that we handle enterprise security has changed dramatically. In the days of desktop computers and no internet, we divided the world into two: the castle, and outside, with a moat dividing the two. The moat and its associated drawbridge was the security. If you got into the castle, you were inside the enterprise and it was assumed you were legitimate, and there was very limited internal security. It wasn't just logging into the enterprise systems, often you had to be physically present inside the enterprise buildings since that was the only way the computers could be accessed. There was the internal network, perhaps referred to as a LAN for local area network. Then there was the networking outside the castle, perhaps referred to as the WAN for wide area network.

Then laptops, and later smartphones, arrived. People needed to be able to work from outside the castle. This was the main motivation for the creation of VPNs, virtual private networks. They allowed employees on their laptops to be treated as if they were inside the castle, without requiring them to be physically present on-site. That worked fine for a time, since all the enterprise's computer systems were inside the castle, the VPN tunneled under the moat, and connected to the internal LAN. Once inside there was a lot of trust and access. Even with VPNs, the world was still divided into inside the castle and without.

Of course, enterprises didn't write all their own software (especially if they were designing chips!). But, for example, if you wanted to bring up a customer-relationship-management (CRM) then you paid Seibel or SAP a lot of money, purchased some servers, locked them in a room somewhere, and then let people log into them. The users had to be inside the castle, either physically or by using a VPN.

The Weather Gets Cloudy

That worked fine so long as we didn't have software-as-a-service, or SaaS. Salesforce was the first significant service delivered this way. Instead of running on a server inside the castle, Salesforce ran on Salesforce's servers. If they were anywhere, they were inside Salesforce's castle. Somewhat bizarrely, their tagline in the early days was "no software", meaning no software that had to be installed. There was plenty of software, but the phrase software-as-a-service had not yet been invented.

Gradually everything moved out of the enterprise, initially to server farms run by the companies providing the service, and then later by companies such as Amazon's AWS or Microsoft Azure that provided the infrastructure. Sometimes providing the cloud in this way is called IaaS, for Infrastructure-as-a-Service.

This caused a big problem for the castle and moat concept since the castle was mostly empty, the computers and smartphones were all over the place, sometimes in the castle, sometimes connected on a VPN, sometimes wanting to connect to a service where there was no benefit added by forcing everything to go from the user, into the castle, and back out again to where the service was really provided.

So why not go straight to the service? This is what is known as zero-trust networking. None of the systems considers itself to be "inside the castle" and each authenticates every user. But there was a fly in the ointment. All those different systems in the cloud had their own password. This was fine when there were one or two, but when every employee might be using a dozen cloud-based systems (payroll, expenses, purchasing, benefits, vacation, and more), then changing a password became an all-day exercise.

Of course, outside of the companies we work for, we still have that problem. We all have subscriptions to dozens of websites, some of which we use so occasionally we can't ever remember our password. Some have baffling limitations. Your username must contain a digit. Why? Or your password must have uppercase, lowercase, a digit within the first five characters, and a special character that can't be at the end. Really? To protect myself from the hacker who might manage to...read a few articles on my magazine subscription.

Single Sign-On

Inside the enterprise, most of us have what is called "single signon". We have one password, and the system uses that single password to log us into all the cloud systems automatically.

A couple of years ago, I came across a great analogy in a blog post called The Beer Drinkers Guide to SAML. SAML is always just known as "sammle", although it does stand for Security Assertion Markup Language.

Imagine you are at a music festival with lots of beer tents. The old, pre-single-signup world, would work like this. You go to buy a beer. They ask to see your ID, you show it to them, they give you a beer. Next time you go to a different beer tent. So they want to see your ID again. Even if you go back to the original beer tent, they still want to see your ID. It is a big festival, it's not like being in a bar where the bartender can remember whose ID he or she has seen or not seen.

The equivalent of single sign-on separates checking your credentials from providing you the service. In the music festival world, it works like this. You don't go to the beer tent first. You go to the wristband tent. They check your ID and then give you a wristband. At any of the beer tents, they just check that your wristband is genuine. They don't need to know what the ID requirements are. Similarly, the wristband tent only knows about checking ID, they know nothing about what types of beer are on sale or even if the beer tents actually serve beer. If you don't understand the system, you show up at the beer tent without a wristband. They then tell you to go to the wristband tent and come back to get service.

In SAML, the wristband tent is the Identity Provider and the beer tents are the Service Providers. When you go to the Identity Provider and get validated, you provide your credentials (username, password, maybe two-factor authentication, maybe a physical token on a USB key) then the Identity Provider creates a SAML assertion (equivalent to the wristband) and provides it via browser redirects to the Service Provider. The Service Provider can cryptographically validate the assertion (similar to making sure the wristband is really a wristband and not just a bracelet). In an analogous way, the Service Provider can redirect you to the Identity Provider and then back again once validated.

There are literally thousands of Service Providers from Salesforce, to Dropbox, to OneDrive, to Concur, to Gmail, and so on. There are fewer Identity Providers, such as Okta, OneLogin, UbiSecure, and more.

There is obviously a lot of detail omitted here, but you should get a general idea: get a wristband, then show it to everyone you want to serve you a beer.

Sign up for Sunday Brunch, the weekly Breakfast Bytes email.