Single Sign-On

There are two kinds of organizations. Those that manage their single sign-on (SSO) system, and those that let their users manage their SSO.

The other day I was in a discussion with a number of security leaders about how important identity management is to your security strategy. Obviously, everyone agreed that identity is very important. After all, if you don’t have a strong identity strategy pretty much no other component of your strategy will be strong. There is a reason that the first function of the NIST CSF is Identity. 

However, the discussion then turned to SSO and whether it didn’t constitute putting all your eggs in one basket, and whether doing so is a good idea.

Yes. SSO does constitute putting all your eggs in one basket.

But, that is a good thing. Why? Because you, as a security leader control that basket. You know where it is. You know how it is configured. You have already required strong multi-factor authentication (MFA) on it. (You have right? If not, stop reading this, go do that, and then come back). 

Users* in every organization have multiple accounts for multiple different services. You have your account for Active Directory, GSuite, or whatever other Identity Provider you are using. You have an account for the Human Resources Information System (HRIS), for the file sharing service with customers, for databases, and for innumerable other services. 

Organizations that recognize the benefits it provides use a managed centralized SSO system (Sign-in with Google/Microsoft/Okta/etc) to provide SSO. They onboard as many services as they possibly can to this system. They provision users with SCIM to it. And, if they are particularly enlightened, they provide staff with a password safe - also tied into the managed SSO system - to store credentials for things that cannot be integrated with SSO. This provides centralized control over most authentication, logging for when and where users authenticate, and the ability to trigger alarms and alerts on unusual or suspicious activity, Superman events, and so on. 

Organizations that do not use a managed SSO system still have an SSO system. However, it is managed by their end users; by just using the same password everywhere. They will because passwords are hard to generate and hard to remember. They get in the way of doing work. Consequently, users will develop their own SSO system because that gets their job done, and that’s what we are paying them for. Even amongst security professionals password reuse is endemic, except among the few who choose to use a password safe for everything. 

Nearly 40 years ago, Gordon Davis published a seminal article: Caution: User-development Decision Support Systems Can Be Dangerous To Your Organization. Professor Davis did not consider how this applies to security. It does. User-managed security systems can be dangerous to your organization! 

You can choose to manage security centrally, professionally, and to defined standards; or you can leave it up to your end-users. I argue strongly that the former is going to be the better approach. When we rolled out a system to scrape password dumps from the “dark web” we learned that, of the usernames that match, 2/3 also matched on the password. Furthermore, when we told those people their password had leaked and forced a password change 40%(!) changed it to the password we told them had already been stolen! Using the same password everywhere is a functional SSO system, and probably the most common one. Our choice as security professionals is not whether to have an SSO system, but rather, whether to have a managed SSO system. 

* By “user” I use the convention that it denotes your internal users; staff, contractors, vendors, interns, etc. Your external users, those who you build your services for, I refer to as customers.