The not-app-building parts of building an app

Large customers require engineers to build several acronyms

When you think of software engineering, you envision developers working hard on customer facing features. But a surprising amount of developer time is actually spent on making apps usable for large companies, a group that has a rigorous and sometimes oddly specific list of requirements. If you’ve heard of SSO, RBAC, or SIEM, you’re in the right place – this post is going to break down how developers make apps enterprise-ready and why a disproportionate amount of time is spent on these seemingly niche features.

Developing applications for larger customers

You wouldn’t necessarily think that you’d build your app significantly differently depending on the size of the company you’re trying to sell it to – but then you’d be wrong. Enterprises – and increasingly common today, just large startups – have specific, rigid requirements for the applications they buy and commit to using. The larger the company, the more customers they have, and the more is at stake: they command higher standards of security, support, and ease of integration from their vendors.

When I hear enterprise sales, my gut reaction is to think of IBM reps wearing Rolexes on a golf course selling multi-year contracts for tens of millions of dollars. 

But the more I worked in startups, I started to realize that enterprise sales is something most business-to-business startups end up contending with one way or another. The “real” money – recurring, yearly, multi-million dollar contracts – comes from larger companies. Pretty much every company I’ve worked at, even ones that were highly developer-focused and community oriented, relied on business models where the majority of revenue came from these “enterprise-esque” contracts. 

The word “enterprise” doesn’t have to mean Fortune 500 companies, by the way – even larger startups like Airtable, AirBnB, Stripe, and the like are starting to demand these kinds of features from their vendors. Tools you might use and love all have (at least partially) enterprise as part of their strategy:

• Notion (here)

• Airtable (here)

• Slack (here)

• Dropbox (here) 

These companies have pretty transparently built teams, features, and marketing motions to cater to enterprises. In other words, it’s a thing most B2B startups will need to figure out – and dedicate engineering time to – eventually.

Let’s make this a little more practical. As a developer working on an app that you hope to (eventually) sell to a larger company, you’ve got a few main things you’ll need to worry about (acronyms abound):

• SSO and SAML – how your customers log in / authenticate to your tool

• SCIM – integrating with your customers directory data so your app knows who everyone is and what permissions they should have

• RBAC – detailed levels of permissions in your app (who can do what and when)

• SIEM – recording audit logs of everything that users do in your app

Let’s dive into each, what they are, why companies want them, and how developers build them.

Authentication: SSO and SAML

The first set of features developers are tasked with building when selling into the enterprise is authentication – essentially how users log into your app. The default is username and password (duh), but enterprises often require something called SSO, or Single Sign-On. In a nutshell, SSO lets you outsource your authentication to a third party app like Okta or Azure AD. The larger the company, the less likely they are to accept traditional username/password from their vendors. 

Imagine you’re a developer at a SaaS startup, and you’re working on building basic login for your app. The simple way to get that done is username and password: 

• When a user creates an account, you store their username and password in a database

• When they want to log in, you prompt them for their username and password

• If the username and password they give you matches what you have in the database, you let them in

• (When they reset their password, you update it in the database)

With username/password login, you are providing identification: the credentials to log in exist in your system (the database). But with SSO, you use credentials that already exist elsewhere – mostly commonly Google, Facebook, GitHub, or Okta for enterprises – instead of collecting and storing it elsewhere. If you’re seen the “Log in with Google” button, that’s SSO. The identity provider – let’s say Google in this case – provides a series of APIs that allows startups like yours to use their accounts for your app. The most popular identity provider for enterprises is Okta, so that’s an important one to consider when you’re implementing SSO.

🖇 Practical Example 🖇

This isn’t just about B2B, by the way. If you’ve recently had to switch over from HBO Max to Max and re-authenticate using your Verizon or Hulu login, that’s SSO and SAML in action right there.

🖇 Practical Example 🖇

To build SSO into your app, you need to develop custom integrations with any of the identity providers you want to work with. Most of these integrations work using a protocol called SAML, which stands for Security Assertion Markup Language. It’s a way for your systems to communicate with identity provider systems in a secure, standardized way. 

Like some of the other protocols we’ll look at in this post, SAML is rather arcane. It uses XML (a pretty old markup language), requires a dedicated server, and necessitates custom work for each identity provider you want to support. There are multiple versions of the protocol and different commercial implementations that are all slightly different.

If you don’t want to implement SSO yourself, you can use a third party provider, and there are a lot more options here than there used to be. You’ve probably heard of Auth0, which ironically enough is now owned by Okta. AWS has a service called Cognito. These provide both (a) identity as a service, and (b) integrations with other identity providers. For a purpose built tool that takes care of SSO for you, check out WorkOS. 

Directory Sync: SCIM

More terms you probably haven’t heard of: Directory Sync and SCIM, or System for Cross Identity Management.

Directory Sync is actually pretty simple. Larger companies maintain an internal directory – just like an address book (or a rolodex for the adults in the audience) – of who works at the company, what team they’re on, what their email is, and the like. It’s a single source of truth for identity at an organization. If you’ve ever worked with Bamboo or Rippling, this is sort of the same thing, but built for programmatic access. A company defines their users and groups, and standard API endpoints let applications work with that data.

Back to our developer at a SaaS company. How is this directory that your enterprise customer has relevant to you? There are a few ways, but the main one is user lifecycle management, and it’s really simple. People get hired, people get fired, people quit, people move teams, people die also. If every developer at your company needs a GitHub account (and they do), that’s a lot of work for IT admins to be doing: manually creating an account for every new hire, and removing accounts when someone leaves. Easy enough for 10 people, impossible for 1,000.

This is where the directory comes in. It has an up to date snapshot of who is employed and what their email is: as an app developer, you can ingest that information and automatically create / destroy accounts based on it. If someone leaves, your app can get notified by that directory system and you can automatically deprovision their account. This helps in a few ways:

• Users at an enterprise automatically get accounts in your tool → more will probably use it → more money for you in the long run

• No “ghost accounts” for users who aren’t employed anymore → fewer vulnerabilities and security risks

These directories are built and maintained in a bunch of different ways, which makes it frustrating to integrate with them as a developer. The open source SCIM protocol lets anyone create their own directory server, but many teams use a managed service like Rippling, Azure AD, GSuite Directory…the list goes on. As a developer you’ll need to build a custom integration for each one in your app that pulls data from it and takes the appropriate actions in your tool.

Like SSO, there are third party tools you can use to integrate with your customers’ directories. Aquera gives you out of the box connectors for SCIM and other directory providers. Although Okta doesn’t provide this directly, it makes it easier to share your Okta data with SCIM endpoints. WorkOS lets you add support for Directory Sync to your app with just a few lines of code, with support for SCIM, Okta, Azure AD, and most other popular directory providers.

Authorization: RBAC

If authentication is how you figure out who should and shouldn’t have access to your tool, authorization deals with what kinds of access and power they should have once they’re in. RBAC stands for Role Based Access Control, and it’s a specific way of implementing authorization.

Think about a tool like Looker, where your team creates dashboards for analytics. Which team members should have access to create new dashboards? Which should just be able to view dashboards? Should someone on the marketing team be able to view financial data? Tools like Looker have authorization systems so your admin can make decisions on the above questions and enforce them.

RBAC in Google Cloud

Granular access controls like the ones Looker has are table stakes for any company of meaningful size to use your app. So how do you build it?

Most companies tackle it from scratch. You start with building a basic data model of the different types of roles – a simple one might just be viewers, editors, and admins – and a UI to allow admins to create and adjust those roles. Developers will usually also implement the concept of groups, so you don’t need to set every user’s individual permissions. Then, for every page, or even action, in your app, you check if the logged in user has a role that allows them to see that page or do that action. It’s a lot of custom work, and differs quite a bit based on what your product looks like.

There have been a bunch of startups bringing RBAC products to market over the past few years. Oso is an SDK for adding RBAC to your app with a slick cloud UI to manage it. AWS recently launched one called Cedar. Zanzibar is Google’s authorization system, which isn’t open source but you can use a product based on it via Authzed. See also Warrant, Styra, and Aserto.

Audit logging: SIEM

CIOs and IT admins (and really anyone involved in security) need full visibility into the apps their teams are using: who’s logging in, resetting their password, and accessing what data. Back to our Looker example: every time a user views a dashboard, runs a query, edits a view, or anything, that’s recorded and stored in a database. Admins can look through that data to audit what data was accessed by who and when. This kind of security-focused log of user activity is called an audit log.

Audit Logging in WorkOS

The data in these audit logs is really important to IT teams at your customers. Some industries (like finance) have specific regulations that require companies to store behavior history in an app. But usually it’s as simple as combing through logs to make sure that the right people have access to the right things, and they’re not mistakenly seeing or using data that they shouldn’t be. 

Building audit logs into your app isn’t a massive ordeal, especially if you’re already sending analytics events via a tool like Segment. The hard part is figuring out the details of which events to send, when, and what the information in the events should be. You’ll likely also need to build some sort of UI on top of those events so your users can look through, filter, and analyze them. Note that often, your users will want to export these logs to a SIEM (Security Information and Event Management) tool like Splunk. So you’ll also need to think about building integrations with those types of tools to get events out of your systems and into theirs.

Most engineering teams build audit logging into their products from scratch. There are tools to help (usually bundled with analytics) that have been around for a while: Microsoft Sentinel and IBM QRadar to name a couple, while newer startups like Panther are making a splash too. WorkOS’s audit logging tools allow you to send your logs to all of the different SIEM vendors like Splunk in real time (so you don’t need to build those connectors yourself).

---

SSO, SAML, RBAC, and the like are the most common things developers work on to support enterprise customers, but they’re not the only ones. Just look at Slack – a tool you probably use without thinking much about “enterprise” – and how much they’ve invested in their “enterprise grid” solution. This stuff is getting more and more common, and chances are your developers are thinking about it.