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.
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.
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.
