The never-ending product requirements of user authorization

This article first appeared on alexolivier.me

I’ve been fortunate to work as a Product Manager across eCommerce, Marketing, Supply Chain, Fitness and Finance, and in every product we always had to tackle how different users got permission to access resources in a system and what actions they could take.

It has been a series of painful projects, taking months out of our roadmap to build and maintain an access control system that met the requirements we were facing. This is a tale of the different hurdles any SaaS company is likely to face.

The Blissful Days of Roles

Much like everyone else we began building with simple roles of users and admins. If you have an @ourcompany.com email then you have full access to everything. This is the easiest place to start whilst you are focusing on building the core product not infrastructure pieces like a permissions.

Most likely if you are selling B2B SaaS there will be some early ask for a read only user to let team members get ‘visibility’ of what is going on without causing any damage. Seems easy to add so a few more checks are put into the code when an HTTP verb other than GET is made.

I started here every time - roles are simple. Life is good and you get to build the core feature set…but then things are going well and you start growing…

Requirement: More flexibility than a standard set of roles

Product Packaging

There will come a point as you start developing more features on top of the core product that someone, likely in a Sales team, will want to start tweaking the pricing and packaging “just for this one big deal” likely at the end of the quarter. Larger businesses expect flexibility in how they can buy software from vendors and the bigger they are the more they expect you to bend. At the same time, as a Product Manager you are trying to work out who should get the new feature based on how the contracts are structured.

This raises an interesting problem as now you could have:

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

Modeling all these different access types in code rather than policies is nearly impossible due to the number variables. 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, and no doubt another repackaging exercise is just around the corner.

Add a new requirement: Request time context to make permissioning decisions such as user current location

Data Locality - Safe Harbour and GDPR

A fun one to add to the list of headaches was when the EU/US Safe Harbour agreement fell through for data sharing across the Atlantic and then GDPR landed on my lap. This now meant that we not only had to locate our data inside the EU but also segregate data access depending on the location of our staff and customers. It required adding in logical access checks at every interaction point based on the location of the user and the region where the customer elected to store the data - a change that touched nearly every single system in our stack at the time. If only there was a single place where authorization was checked.

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

Enterprise Organizations

In a couple of businesses, we were targeting larger enterprise customers which came with a whole new set of authorization challenges. When working with a trans-national business and specifically working with a single department of it at first, being able to reflect the org structure in your permissions quickly becomes a sticking point.

Requirements start appearing such as:

• Users should only be able to access things within their department and geography
• Managers in the London office should be able to access everything in the other UK offices
• Head of Departments globally should be able to do everything in all regions
• VPs want to see everything but don’t really know how things work so should only have view access
• Sally in the Paris office is our superstar employee who also does work now and again for the US team so should have access to their account on every 3rd Tuesday if it is a full moon (might have exaggerated a bit here)

Needless to say this led to many frantic whiteboard sessions and hacking around of the access control logic that was in place to try and support the tasks for our latest customer. After some compromise we got something that was acceptable but now the code base was looking more like a bowl of spaghetti than code.

Yet another requirement: Dynamic permissions based on the organizational structure of the customer

Compliance

Now in order to win those enterprise accounts in the first place, we had to cross the compliance hurdles.

One way to do this is to get certified so we spent a couple of years going through the process of obtaining ISO 27001. This requires all sorts of documentation, audits and hoop jumping and one area that as a PM at the time I was called upon to demonstrate was how access controls were set up in our SaaS platform.

I particularly remember being summoned to a meeting room in the basement by our in-house council to meet with a steely-eyed auditor where I had to demonstrate how the product:

• Limited data access for different customers
• Enforced access controls for different user types
• How our internal teams had limited access to customers data unless needed
• The 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

Needless to say a lot of engineering time was spent ensuring we could cover all these areas - at least 3 months of a whole product squad - and it took us away from the core product.

Oh look, one more requirement: Granular auditing and fine grained access controls to meet compliance standards

Enough of this, time for a solution

Through the various hurdles I’ve faced and sure many of you have also, our requirements for authorization have gone beyond roles and now include complexities of:

• 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 controls to meet compliance standards

So after battling these challenges for way too long, I’ve finally bitten the bullet and decided to do something about it. We have launched Cerbos and I’ve taken up the reigns of Product to build a system that will solve this once and for all.

Everything is being built in the open and we are fully embracing an open-core model for anyone to pick up the service and put it into your infrastructure so you don’t have to face the same problems I’ve had to.