Introduction

Modern SaaS vendors build multi-tenant applications: rather than hosting one instance of the software for each customer, they host deployments that serve many customers at once. Amortizing the operational costs across many customers is what makes cloud economics work.

Multi-tenancy is extremely hard to retrofit after the fact. Most software vendors that start as single-tenant software fail to make the transition, and the ones that do have often had to build their multi-tenant offerings from scratch. The designers of nearly every successful SaaS application will tell you that multi-tenancy has to be designed from the start.

As we’ll explore below, secure access and multi-tenancy are inextricably tied together, yet most SaaS application vendors fail to realize how much. Just like multi-tenancy, access control has to be designed from the start.

What exactly is a tenant?

In its essence, a tenant is a unit of isolation and sharing. As a customer, I want my data separated from every other customer’s data. I also want to be able to share my data with other users in my organization.

Because it is fundamentally about isolation and sharing, multi-tenancy is deeply intertwined with access control.

The isolation challenge

An inherent part of the bargain that SaaS vendors make with their customers is that no customer can ever access another customer’s data. Since the vendor is operating a deployment that serves many customers at once, the vendor must build in access control from the start.

The sharing challenge

At the same time, business software always includes collaboration across the users of the organization. Different types of users in a tenant may have different permissions or roles. Once again, the vendor must build in access control from the start.

Cross-cutting roles

Businesses have partner firms that perform specialized work. Most businesses have a law firm and an accounting firm. Many businesses partner with an auditing firm for compliance. And many two-sided marketplaces have suppliers that provide services to multiple customer organizations.

In all these cases, users that are external to an organization need limited access to data that resides in multiple organizational tenants. Once again, the vendor must build in access control for this scenario from the start.

Secure from the start

For new SaaS applications, designing for multi-tenancy is a given. But as critical as it is to the success of a SaaS application, everywhere we look, access control seems to be an afterthought. As a consequence, almost every SaaS vendor we’ve talked to has needed to reinvent their permissions and roles, often more than once.

We find ourselves in this sad state because unfortunately, there are no standard patterns, solutions, or software that make it easy to build access control correctly from day 1. Or, for existing applications, make this redesign be the last redesign.

But a new day is coming. We’re seeing a new generation of developer-centric vendors that are building those standard patterns and solutions, saving SaaS companies the trouble of having to reinvent this wheel. What do they include?

Access control requirements

Standard patterns. There are a set of access control patterns such as role-based access control (RBAC), attribute-based access control (ABAC), and access control lists (ACL). Access control systems should be turnkey to start with, and offer evolution from the simple to the sophisticated.

Separation of authorization policy from application code. Embedding access control logic inside of the application code is a recipe for a long and painful rewrite. A modern access control solution provides a separate component that applications call to perform authorization, and access control rules are stored and versioned separately from the core application.

Users as first-class citizens. Every access control operation is done in the context of a user, whether it is an end-user of an application, or a machine account. The access control system must pick up user context from the identity provider, and the authorization policy should be able to reason about attributes and roles associated with that user (or machine) context.

Fine-grained access control over resources. Granularity of access control is a continuum: on one end, an access control rule may apply to every resource in a tenant. On the other end, each resource may have its own unique access control list. Often, the desired granularity is somewhere in the middle – resources in a group (or under a project) are all governed by the same policy. An access control system must be flexible enough to support this continuum.

Audit trails for every access control decision. Every SaaS vendor that aspires to sell into enterprises must integrate with their customers’ compliance requirements. The access control system must store and make available the decision logs for every access control decision.

Summary

Any multi-tenant SaaS application implicitly brings with it some level of access control. But most applications aren’t deliberate about the design of their access control system, and accrue architectural debt that is really hard to pay off as the application grows. To avoid a painful evolution, applications should design their access control model from the very start.

At Aserto, we’re building a flexible authorization system that is easy to incorporate from day 1, and that scales to the size and scope of your most demanding enterprise customers.
What access control requirements does your SaaS application have? Reach out to us on twitter, contact us, or sign up for a free Aserto account!