Part two of my end of year posts regarding authentication. Sometimes it feels like technologists want to build a mansion for their users. Once you’re In the mansion, all doors are open. And for a unified suite of tools that one might use in, let’s just say, an office, that’s a rational approach.
But security still cares a lot about segregation. So the impulse to create a single sign on (SSO) flow for every application you are offering your workforce may not be the best approach. Here are the two arguments I can make:
- Authentication can be liability. Whatever system authenticates the user is establishing itself as the authority on that user’s authenticity for that session. Tautological as that last sentence is, let it sink in. “I, System A, say you are who you say you are.” In an SSO scenario, System A is more verbose: “I, System A, claim the right to tell you Systems B, C and D, etc., who is and isn’t who they say they are.” The problem comes up when System X is a financial application where the liability for losses is held by the company (firm X) that runs System X and that company is NOT the one that runs System A (firm A). Or even more extreme, the liability for losses on System X is covered by an insurance policy held by firm X but the policy is only good if firm X authenticates users. It will take more than a slick OAUTH transaction to convince the insurance carrier to trust firm A’s security. In the meantime, the well-meaning technologists who set up SSO between System A and System X just created a huge risk. Similar argument here if System X holds very sensitive data/mission critical applications and System A does not (say an HVAC control system versus a cash register control system).
- Inadvertent elevation of privileges. I know, I know, I know: authentication is not the same as authorization. But in the absence of an Identity Management system controlling roles, a rush to SSO may end up giving users way too much authority in a system than they should have. It’s preventable in many ways. But any house guest that ever accidentally walked in on their hosts at an inopportune moment knows once you’re in a house where the doors are all unlocked, bad things can happen. It’s about control and process at that point (didn’t you think to knock?). As we in security know, many security flaws are introduced inadvertently in the name of making things easier for the end user.
One of my security colleagues has been patiently sitting at the table waiting to object. Now that I’ve made my two points, they politely explain to me that the GREAT thing about SSO is that once you suspend access to the single point of authentication, you’ve cut off access to multiple systems. It’s efficient. It’s LEAN. It’s a strong control. Sure. But then you’re not talking about single sign ON, you’re talking about single sign OFF. If you’re designing with an eye towards security, you might build a single point of de-provisioning access and logging a person off of multiple applications even in cases when it is inadvisable to have single sign ON.