Security 101: Identity Providers

There are only a few things I am aware of that most startups care less about than employee management, on and off boarding and access management. Especially when just starting your journey with two friends it sounds like something totally unnecessary… and then you hire your first few employees. Obviously you conduct - what you believe to be - a job interview, and you are obviously sure you hired the absolute right people. Why add tons of additional work? You can trust them. You hired them. They are „good people“. Right?

Wrong.

You might actually be right, but this will be an outlier as you grow your company. You sometimes will hire the wrong people. Maybe they are not as productive as you expect. Maybe they do not play well with your existing org structure. Or they struggle with adjusting to the size of your team. Maybe they turn out to be assholes. Fact is, at some point you will have to let people go. And if you do it for the first time - maybe for the first 50 times - chances are pretty high you will make mistakes. Chances are also pretty high people you let go will be displeased, at least.

What is the worst that can happen? They might delete your production infrastructure. They might push malicious commits to your repository. They might dump your database and sell it to a direct competitor. If you believe this is far fetched you are way off. All of the above happens, more often than you believe and more often than anyone of us likes.

The inevitable truth is that as your organization grows people you have hired will do things that will cause harm to your company - out of spite, not knowing better or simply an accident. From my experience this is one of the toughest lessons to communicate to a founder or small team. Something we do not like, because it means admitting we made a mistake hiring someone, overestimated their capabilities or did not foresee that we are all humans and make mistakes on a regular basis.

One of the most fundamental parts of your software environment will be an identity provider. An IdP usually has at least two responsibilities:

  1. manage user accounts for all your employees
  2. provide a way for other systems to authenticate and authorize users

You create exactly one user account when you hire an employee. You assign them one or multiple roles and once they set a password and complete the two factor authentication setup they are granted access to all relevant systems. You part with an employee and you deactivate the account in your identity provider, blocking access to all of your company systems. This is obviously the very simplified description of an IdP and most services and systems provide additional functionality (like authenticating system users on employees laptops or integrating with your network gear).

Picking an IdP is a bigger deal than choosing an analytics solution you can swap for a new one by replacing a pixel or a few lines of JavaScript. Your IdP on the other hand will be - ideally - tied to every single system you use. Every single one. Switching providers is expensive and error prone. Which is one of the reasons why the sales teams of most companies operating in this sector are far better than their support.

So how to best approach this problem? I would suggest incrementally. Most software you will be using early on should be able to leverage Google for SSO. Paired with G Suite, which most startups will likely be using anyway, you have a solution in place that checks most of the boxes.

This is one of the points where I support pragmatism over best practices. You will not be able to reap all the benefits of an IdP with Google. Actually far from it. But you are able to easily on and off board employees and enforce some security best practices. I consider this a win. And it gets out of your three person teams way, so setup and maintenance are not an excuse to fall back to sharing a single account via Slack among all people.

There will be a few apps that will not support Single Sign On (SSO). In this case there are two options. First: use something else. Second: talk to them and see if they can provide SSO. If both options are not viable you will have to fall back to creating user accounts. Plural, please. Add an explicit action item to your off boarding checklist to deactivate or delete those accounts. Also - create the checklist.

As your team grows you want to move to a more advanced solution like JumpCloud or Okta. But this will come with additional maintenance requirements. You will need to understand some concepts like SAML and find your way through interfaces not adhering to any standard but assuming you already know exactly what you are doing when you upload your newly generated SSL certificates. Most of the time SAML also comes with an enterprise plan you have to pay for. Only enterprise users care about security and an IdP, right? And enterprise users always have a lot of money to burn, right? SaaS vendors artificially gate security features, and from a vendor perspective this makes a lot of sense. For you it sucks.

Once you adopt an IdP I would suggest going all in: Let it manage your SSH keys to ssh into your servers. Use it for system logins. Use their Radius server to authenticate users connecting to your WiFi. Go through their feature list and try to use them to its fullest. The less manual steps you have to take and the faster you can deactivate accounts - including in the event of one being compromised - the better.

As I said earlier: This is some serious work to get it all right and rolled out. But it is one of the things that actually moves the needle on the security meter quite a bit.

If you want to follow this article series you can either subscribe to the main RSS feed or to the tag specific one if you only care about startup security posts.

>> posted on May 26, 2020, midnight in security, security101