Why are we building Cerbos?

We are building Cerbos because when it comes to building key pieces for software infrastructure and frameworks, we believe software engineers should not reinvent the wheel.

Authorization is often an inconvenient necessity -- especially for new projects. You have a great idea, build a prototype, iterate, refine and finally you’re ready to productionize. It’s at this point you realise that you need some kind of access control in place. It’s frustrating, unexciting, complicated and time consuming to build. So, more often than not, developers tack on the bare minimum system that gets the job done for the time being. Usually it’s something along the lines of “superuser” (ability to do anything), “editor” (create or modify anything) and “reader” (only view things).” This works reasonably well if the product stays the same forever. However, successful products evolve rapidly and in ways that no one can predict. That is when the simple access control systems start to fall apart and start to hinder product development.

As more users are added and new functionality is built, it is inevitable to require much more fine grained access control. A handful of simple roles is just not enough; you have to support exceptions that arise from the different ways in which your customers’ organizations are structured (or re-structured). Eventually, a significant portion of your development efforts will revolve around refactoring, testing and scaling the access control code that is now inextricably weaved deep into the application source code. Adding a simple feature is not so simple any more because the developers have to spend time understanding the existing access control logic, figuring out how to extend it (praying that it doesn’t involve a database migration), and testing it to ensure that the change does not break something elsewhere in the code. In a large project with many components, modules and developers, this is a huge undertaking.

We have experienced this pain first hand many times during our careers. In one particularly fast evolving system that started out with a simple superuser/not superuser type of access control, one of our former colleagues who happened to have super powers, thought he was operating in a test environment and ended up pushing a picture of a floating palm tree live on a major retailer’s website. It was not due to malice. It was due to not having proper controls in place.

This problem exists in every company whose product involves more than one user in different roles to complete a workflow. Different roles mean different responsibilities and permissions to perform different actions.

Authentication is a solved problem by big established players like Okta, ForgeRock, Auth0; and every day it keeps improving. Authentication is about user identity (or application/service identity, collectively known as a principal) and authorization is the natural step after that. Once a principal’s identity is established via authentication, the authorization layer controls what actions that principal can perform on each resource based on the context.

Authorization -- or, simply, user permissions -- is what Cerbos is focusing on. There are many different types of access control paradigms: role based, attribute based, context based, rule based, organization based, relationship based, graph based, access control lists, etc.

We are starting to tackle the challenge one step at a time.

Today, many organizations build their own authorization layer. Once upon a time Authentication had a similar start. After all, how hard could it be to look up a username and password? We all know that the security landscape changes at an unimaginably fast rate. A static password lookup table is no longer a secure solution. You have to think about salting, hashing, password rotation, 2-factor authentication and a whole lot more. The investment required to keep abreast of the security best practices and implement them is too high for most organizations so they are more than happy to outsource that responsibility to a third-party authentication provider.

Our mission is to make permissions simple to build, deploy, manage, evolve and report on, thus freeing up developers to focus on their core product and delight their users by shipping new features faster with high confidence that the access management layer is not going to break unexpectedly.

Nowadays, when developers need a database, they do not write their own database engine (unless that is what they set out to do in the first place). There are many excellent database products to choose from and they have well-defined interfaces that applications can interact with easily and quite simply, we want to bring that level of sophistication to the authorization space. It’s easy- tell Cerbos who your principal is, what actions they are trying to do on which resource, and get a simple yes/no answer back.

Cerbos aims to decouple authorization logic from your code and make it accessible from every layer of your architecture with no more code duplication or inconsistencies. Most of the time, changing the access control rules won’t even require a code redeployment. You have more freedom to experiment and build things without worry.

Whether you use Cerbos or not, we are advocating for a very clear permissions API. One should not need to change the application code when the business logic changes.

As founders of Cerbos we have experienced the pain in both very large conglomerates and in growing startups. We are here to help the world solve this problem in a user-friendly way.

Emre & Charith