5 Factors to Weigh When Building Authorization Architecture

This article was first available on The New Stack - read it here.

A permissions layer is not something you would generally focus on when building a new software application. Your primary goal is to reach product-market fit as quickly as possible, so you focus on delivering the core business value and everything else takes a backseat.

Across the team at Cerbos, we’ve been fortunate to work previously at companies across a wide variety of industries — including ecommerce, advertising and supply chain to name a few — and every product we developed always required us to consider how different users gained access to resources and what actions they could take.

Every attempt at this problem has been a painful one, demanding months from our roadmap to build and maintain an access control system that met our customers’ needs.

This is the story of the hurdles any Software as a Service (SaaS) company — perhaps your company —will face as it embarks on a product-creation journey that demands new thinking about authorization. Read on to find out what we’ve learned, and save yourself some headaches.

1. Us vs. Them

At the outset, you can rely on a simple model of users and admins. If you have an @ourcompany.com email address, you have full access to everything. This is the easiest way to start building the core product. Many of our users started out granting broad access to their software, while we focused on developing infrastructure elements like permissions.

If you are selling B2B SaaS, there is likely to be an early request for a read-only user. This will let members of the team see what is going on without causing any damage — and seems like something that can be easily added into the code: so a few more checks are put in place when an HTTP verb other than GET occurs.

Ninety-nine percent of the time, you will have started here. The roles are simple. Life is good, and you get to build the core feature set. But then things start going well, growing quickly, and suddenly your codebase has become a monster — with disparate, complicated and fragile business authorization logic spread all over the codebase.

Requirement: More flexibility than a standard set of roles.

2. Feature Gating

As you continue to develop new features on top of the core product, you may receive requests from sales teams to modify pricing or packaging. More mature companies expect flexibility in how they can buy software from vendors and request more customizations than younger companies.

As a product manager, you need to decide which customer gets new features based on contracts that are structured differently for each customer.

This raises an interesting problem, as now you could have:

• A customer cohort on a legacy contract with a set of products.
• Another cohort of users on the latest contract with a different set of products.
• A customer in a time-limited trial or proof of concept period who needs some, but not full access.
• A super important enterprise account that has a custom contract, which grants them access to the usual product set plus this one extra thing which would have “been a deal breaker.”

It is nearly impossible to model all these different access types in code rather than policies. However, it is possible to do some cleverness using a database storing all the different access, but then you have just spent valuable engineering time building infra, not product. Another repackaging exercise is likely around the corner.

Add a new requirement: Request time context to make permissioning decisions, such as the user's assigned package limits.

3. Going Global

When the European Union/U.S. Safe Harbour agreement fell through, the environment for data sharing across the Atlantic shifted significantly, and then the EU’s General Data Protection Regulation (GDPR) landed, closely followed by California Consumer Privacy Act (CCAP), and a number of similar regulations are working their way through the courts across the world.

These restrictions now need to be handled at the core permissioning layer of a system to ensure data is segregated. Access now depends on where our staff and customers are located.

This requires the addition of logical access checks at every interaction point, based on a user's location and the region where a customer elected to store the data. This sort of change touches nearly every system in a stack

And another requirement: Rich information about the user beyond their role, such as location, to make decisions upon.

4. Scale to Enterprise

As you succeed, you will inevitably want to start winning some larger enterprise customers. This means working with a whole new set of authorization challenges. When working with a transnational business — and, specifically, working with a single department of it at first — reflecting the organizational structure in your permissions quickly becomes a sticking point.

New requirements emerge, such as:

• Users should only be able to access resources and data within their department and geography.
• Managers in the London office should be able to access everything in the other U.K. offices
• Heads of departments globally should be able to do everything in all regions.
• Company vice presidents want to see everything but don’t really know how things work, so they should only have view access.
• Sally in the Paris office is our superstar employee who also does work now and again for the U.S. team, so she should have access to their account every 3rd Tuesday if it is a full moon (might have exaggerated a bit here).

From our experience, we have to spend several frantic whiteboard sessions working out the access-control logic for each task and hacking around the existing code base in order to support our latest customer. After some compromise, we come up with a solution tha’s acceptable — but now the code base looks more like a bowl of spaghetti.

Yet another requirement: Dynamic permissions based on the customer’s organizational structure.

5. Certification and Audit

To win enterprise accounts, the compliance hurdles get higher and the burden on the team gets larger. One way to mitigate a lot of this repetitive compliance work for each customer is to obtain an ISO 27001 credential, the international standard for managing information security. This entails a number of steps, including documentation and audits.

One particular memory of going through this process is being summoned to a conference room by our in-house council to meet with a steely-eyed auditor, to whom we had to demonstrate how the product:

• Limited data access for different customers.
• Enforced access controls for different user types.
• Limited access to customers' data for our internal teams, unless needed.
• Had a process to gain access to customer environments for support reasons.
• Enabled customers to manage their own permissions
• Provided an audit trail of any changes to authorization or suspicious access

Given the scope of our project, we had to allocate many resources to cover all these areas—at least three months for a whole product squad. And it took us away from our core product.

One more requirement: Granular auditing and fine-grained access controls to meet compliance standards.

Be Scalable from Day 1

Through the various hurdles, we’ve faced in helping customers — and surely many of you have also — our requirements for authorization have gone beyond roles and now include:

• More flexibility than a standard set of roles
• Rich information about the user beyond their role, such as location, to make decisions upon.
• Dynamic permissions based on the organizational structure of the customer
• Granular auditing and fine-grained access control to meet compliance standards

So after battling these challenges for way too long in our work at other companies, we’ve finally bitten the bullet and decided to do something about it, and launched Cerbos. Everything is being built in the open and we are fully embracing an open-core model, so you can pick up the service and put it into your infrastructure — so you won’t have to face the same problems we’ve had to.

This article was first available on The New Stack - read it here.