Deprovisioning: what does "deprovisioning" mean in business software?
If you've found your way to this guide, you've probably heard someone talk about provisioning or deprovisioning in business software (SaaS). Moreover, if you're anything like most people, you're feeling a little bit confused. That's totally normal.
I promise this stuff isn't so complicated! The world of identity and access management just has a ton of impenetrable jargon. That makes life hard if you're just trying to grasp the basics.
In this article, I'll do my best to explain what provisioning and deprovisioning are. Let's start with a TL;DR.
TL;DR! What is deprovisioning?
Deprovisioning pretty much always just means you're removing a user. Provisioning, as you might imagine, basically just means that you're adding a user.
Underwhelmed? Yeah, I told you this stuff wasn't that complicated!
Wait... so why is deprovisioning even a thing?
Control over business software
I skipped a bunch of important context. Let's back up a little bit.
Think of some examples of business software, the applications you use at work. You might use something like Slack or Zoom daily. Maybe you get payroll via ADP or Workday. You might have filed expenses in Expensify or Concur.
These applications all share one critical characteristic. Individual employees aren't buying them. It's not like Randy in Contract Administration is personally getting a monthly invoice for his Zoom license. (Even if he does make unusually gratuitous use of the virtual backgrounds.) Instead, it's the company that buys business software.
The company always wants control over its users. That's for both practical and security reasons.
Every employee needs access to some subset of business software applications. Not everyone should have access to every application. If you pay for Salesforce CRM on a per-seat basis, you don't want to needlessly spend $100,000 on seats for the software engineers; they're never going to log in anyway. And then you definitely don't want the interns to get superadmin privileges in the business bank account; that responsibility belongs to the CFO.
Especially in big companies, managing employees' access to systems is a pretty complex job! There's a lot of work to do.
Identity providers
Managing employees' access to systems gets complicated fast. You just can't handle it all manually.
Companies of a certain maturity almost universally use specialized software applications called identity providers (IDPs) that their IT teams manage. At the risk of oversimplifying very complex systems, IDPs serve basically two core functions:
- They keep track of the current state of employees and employees' access to systems. If IT learns that a new employee has joined the company, there will be a new entry for that person in the IDP. If someone in the company relocates to the Tokyo office, part of the transfer process will likely involve changing his personnel record in the IDP. In this sense, IDPs are glorified databases.
- When the IDP notices that certain data changes, it can be configured to relay information about those changes to certain software applications. For example, certain software applications like Slack may want to know about your job title. If you get promoted, your job title changes -- and applications like Slack will want to get alerts!
Common IDPs include products like Okta, Microsoft Entra, Microsoft ADFS, Sailpoint, OneLogin, and more.
The most important information from identity providers
IDPs can keep track of a ton of information. But their most important information by a very wide margin is a list of mappings between people and the software applications they're supposed to use, e.g.:
- GitHub users are Linda Yang, Trent Struble, and Tammy Kessler.
- Dropbox users are Evan Blandon, Todd Jaspin, and Eve Brown
- (and so on)
It's critical for IDPs to relay changes in those mappings, largely because insider attacks present a real threat. (Sabotage by former employees is extremely common, e.g., at Disney.) When someone parts ways with the company, the IDP needs to issue a blanket shutdown notice to all the relevant applications. That person's account needs to be turned off.
This is what we mean by deprovision It's a corporate identity provider issuing notice to a software application: remove this person's account.
It's kind of like a big red button for access management.
I need to support programmatic deprovisioning in my software. How do I do that?
Enterprise customers will very commonly request that you support this kind of deprovisioning. They do need it -- it's a really important security feature. So if you're a software developer or a product manager, you have some work to do.
There's good news and bad news ... and then good news again:
- The good news: this kind of deprovisioning is handled over a standard protocol called SCIM (the System for Cross-Domain Identity Management). In principle, SCIM means that you don't need to build complicated bespoke integrations with every enterprise customer's identity provider. I discuss SCIM in great detail here.
- The bad news: it is extremely unlikely that you ever see a real customer's identity provider play by the rules. People simply do not implement the standard correctly. You will be very unhappy if you try to implement SCIM yourself. Here again, you can reference my detailed SCIM explainer for examples.
- The good news again! You don't have to implement SCIM yourself. You can use a managed service like Tesseral to handle SCIM on your behalf. Tesseral is comprehensive, open source auth infrastructure for B2B SaaS. With just a few lines of code, you get advanced enterprise features like SCIM -- and more -- and you don't have to worry about it ever again!
