Rolling out Single Sign On (SSO) incorrectly can backfire dramatically and impact your overall rollout and adoption rate. This guide is meant for anyone responsible for rolling out SSO in an organization. It’s based on years of experience with SSO and various environments.

Why SSO Is Important

Let’s first talk about the why. Feel free to use any part of this guide to gain budgeting for your project 😊.

Single Sign On has the following benefits in an organization:

It increases security while at the same time improving convenience. It’s one of the few times a security implementation will increase convenience. Historically security has been inversely proportional to convenience, but that’s changing with new technology.
Reduce onboarding time. When SSO is well configured and humming along, onboarding new people is effortless. Ideally each person will have a role with a pre-configured number of apps and permissions and voila, they have access.
Meets compliance requirements (Access Reviews). Whether it’s SOC2, ISO, PCI, or just good ole security best practices, conducting access reviews is 1000 times easier than manually checking each application. The idea is that to access app X, you can only do so via SSO.
No more stragglers with access. The #1 identity issue I see at companies is former employees and contractors with access to corporate applications, information, or infrastructure. (In case you’re curious, #2 is excessive permissions or too many admins.)

Step One - Figure Out Your Primary Identity Source

Before doing anything, you will want to figure out what will be your source of truth for identity. This is step 0 for where identities will be created, suspended, and deleted.

Primary Identity Source - HRIS (Best)

Ideally your company will have an Human Resources Information System (HRIS) in place where they do their onboarding and onboarding for BOTH employees and contractors.

Why is this the best method?

Well, before IT is involved, HR / People Ops are the first ones to know when a person is going to start or leave. Additionally, they have all the right information such as First Name, Hiring Manager, Start Date, etc.

If you do have an HRIS you will want to have automated integration between your HRIS system and SSO provider.

Of course this assumes you have an HR person or Dept. 😂 #startuplife

From what I have seen, companies with more than 250 employees have some sort of HRIS system.

Primary Identity Source - SSO Provider

In this scenario your SSO tool of choice is the PRIMARY way your company add and removes users at a company. While this is not necessarily a bad scenario, it means the right information needs to get to the IT department.

This is generally the default choice if you do not have an HRIS system or a small company of 100-200 employees or less.

Step Two - 📃 Inventory Your Apps

A lot of companies miss or overlook this step. They either don’t realize all the apps in use at a company or how important they are to various folks.

Understanding all the applications in use and by which teams will be critical in figuring out the roll out plan and later on defining the various roles

💰 The Cost of SSO

Unfortunately and ever so increasingly, companies are adding additional costs for security of their SaaS Apps, such as audit logs or SSO. A previous colleague of mine even set up The SSO Wall Of Shame that tracks the increase in price for SSO as a feature.

Understanding the total cost of the SSO project is important, especially if you’re using Github, where there is a 425% increase in price!

Having SSO for Github is essential though, as you don’t want stragglers with access to your source code! (ps. It’s a pain to configure!)

Step Three - Figure Out Roles 🧻 (Optional)

Don’t get me wrong, this is an important and useful step… but I know startup life and I don’t want to make this a blocker. However it will save you time down the road.

Figure out the various personas at your company and the associated app they might be using. For example:

Execs - Google, Slack, Asana, BambooHR

Engineers - Google, Slack, Github, Atlassian, BambooHR, PagerDuty

Contract Engineers - Google, Slack, Github, Atlassian

Creating roles will allow onboarding requests to go through much faster and smoother.

Each app will have its own role as well, which I did not list above. So the matrix can get pretty big.

Can you imagine every time you want to onboard someone the Hiring Manager has to select from a list of apps, then the IT Admin has to manually add them to those apps. Not to mention, IT might not know what role they may have.

You generally want to avoid manual processes. The more manual a process, the increase in likelihood of a security misconfiguration.

What could go wrong? Here is an examples:

An employee gets the wrong role in BambooHR with access to information they shouldn’t have

Step Four - Figure Out Your 2FA Plan

Since this is a disruptive change, you want to make sure to include 2FA in your rollout plan. However, choosing the wrong 2FA will make or break your implementation. So be thoughtful in how you plan on deploying.

Here are some choices and my thoughts on each:

Push notification using the providers app (Best)

Using the provider's application and configuring PUSH notification (not TOTP codes by default) is the best way to go. Everything is managed in one application and getting a push notification is way more convenient than using codes, although not necessarily more secure (see below).

Note: Train your users to never agree to an authentication request they did not request. This is a known attack method, and sometimes people are just pavlov’s to hit yes on these apps.

Hardware U2F Tokens such as Yubikeys (Good)

Hardware tokens are a good approach and offer extremely high security. Some things to consider:

Devise a plan when (not if) hardware tokens are lost or stolen
They have a high initial cost, but may pay over time vs the push app
Not everyone has the same connector. USB-A, USB-C, Bluetooth, etc, etc…

Some reasons to use a hardware token:

Cannot use employee / contractor phones for business purposes
High risk users - CEO’s, International Travelers, IT and Infrastructure Admins

TOTP Authentication Codes such as Google Authenticator, Authy, 1Password (Least Recommended)

Time-based One Time Passwords (TOTP) are codes generated based on an initial secret key. This method is tried and true, but the major downside is that it’s not centrally managed.

Not centrally managing anything in an SSO ecosystem is not recommended at all.

There are certain situations where a subset of users may have to use TOTP codes such as customer service or call center folks not allowed to have personal phones for example. In this situation, using 1Password for 2FA codes would be an efficient and centrally managed solution to meet the need.

🚫SMS Authentication

Do not include SMS authentication as any part of your SSO deployment plan. Just don’t.

Step Five - 🚀 Deployment & Communication Plans

With all of the above information you should now understand the level of effort needed, including the time needed for the upgrade of apps, and can now put together a deployment and communication plan.

Here are my suggestions for a smooth deployment.

Use the 80/20 rule to your advantage. What apps do 80% of all users use? Begin pre-configuration of these apps.

💡Tip: Avoid deploying SSO without all the applications pre-configured. Having all (80%) apps available on Day 1 will increase the usage of the SSO platform and reduce the number of people forgetting their passwords.

Divide all users into the following groups and reapply the same rule:
1. Pilot Users
  1. This is a group of pilot users from a variety of the groups above to help work out the kinks of your deployment
2. Engineers & Engineering Managers
3. HR / People Ops
4. General Users
5. Execs & White Glove Users

This is probably the general order you will want to deploy, but depends on your organization. Sometimes we recommend starting with Execs so they can advocate for the platform or if they are doing some high risk activities. Doing it last will make sure everything is smooth by the time it gets to them.
Engineers can be a great to start with as they typically like new tools and will be more technically savvy. They’ll also give you feedback on improving the process without asking! 😆

Create a communication plan. This is a major change, so let’s over communicate and plan on some hand holding along the way.
1. Create detailed documentation on how to set up SSO. Include a video📺 if possible.
2. Get executive and HR buy in regarding the deployment and communication plan. You don’t want to conflict with other events and activities and add unnecessary stress. This will cause your project to stall.

Have staff available and ready to provide support as needed.

Conclusion

Deploying SSO is a very disruptive process that requires a lot of planning, cross-functional input, communication and coordination. The more effort you put into proper planning, as anything, the smoother the deployment process.

Last Week As A vCISO

A Complete Guide To SSO Deployment