Navigating the complexities of authorization in software development

In a talk at a recent conference, Emre Baran, Co-Founder and CEO of Cerbos, delved into the intricacies of authorization in software development. The focus was on the challenges faced by developers in balancing security and compliance with a rapid development pace. This blog post distills the key points from Emre's talk, especially for those who prefer a quick read over watching the full video.

The developer's dilemma: Building vs. opting for solutions

Emre's talk began with a reflection on his experiences at Google, CGI, and his startups. He emphasized a common scenario where teams dedicate significant time to developing infrastructure unrelated to core business problems. This dilemma often leads to questioning whether to build solutions from scratch or to seek existing solutions.

Train 1: User and role complexity

As Emre explained, in the early stages of product development, focus is usually on a single user type, leading to simple authorization structures. However, as the user base grows, so does the complexity. More user roles emerge, necessitating a sophisticated approach to authorization. This growing complexity can lead to a metaphorical 'train crash' if not managed properly.

Train 2: Technology stack expansion

The second 'train' in Emre's analogy relates to the technology stack. Initially, startups may have a simple stack, but as the product evolves into a business, the technology stack diversifies, incorporating multiple microservices and technologies. This expansion demands a more complex authorization system, putting additional strain on development resources.

The solution: Building smarter, not harder

Emre Baran advocates for leveraging existing solutions to avoid reinventing the wheel. He stressed the importance of acknowledging the potential future maintenance costs and the long-term impact of developing in-house solutions. Building smarter means utilizing tools that are already available and proven to solve similar problems.

Cerbos: A pioneer in authorization

Highlighting Cerbos' role in this landscape, Emre described how Cerbos was born out of a need to simplify authorization. Cerbos focuses on providing a robust, scalable, and secure authorization solution. It's designed to be fast, reliable, and to offer a great developer experience.

Key takeaways

Emre's message to developers is clear: focus on the core business and avoid the temptation to build everything from scratch, especially in areas like security and authorization. He encourages developers to consider existing tools like Cerbos, which can save significant time and resources while ensuring compliance with security standards like GDPR and CCPA.

Conclusion

Emre Baran's talk serves as a crucial reminder for software developers and business leaders alike. In an era where compliance and security are paramount, choosing the right approach in software development is more critical than ever. Cerbos stands as an example of how choosing smart, ready-made solutions can empower developers to focus on what they do best: building great software.

Transcript

Thank you, P. J. My keynote is gonna have two common things with the previous one. One, we're gonna talk about developer tools. Two, there will be no mention of A. I. or L. L. M. So let's talk about building smarter and not harder in the context of authorization and infrastructure software building.

I worked at Google, conglomerates like Google and CGI, and I also built three of my own startups. And in every single one of these, that throughout my career, we've lost countless hours building and implementing infrastructure that had nothing to do with the core business problem that we were solving.

Our story - we're gonna talk about the story of a developer. Can I see a show of hands, how many are developers here? Alright, good. We have a good mix here. So we're mostly software developers on this stage, and what does that mean? That means if there is a problem, if there is any problem that we see in the code, we have an attitude of, I can solve that with my code.

However, how often is that writing, our own code, is the right answer? Just because we can, how hard sometimes do we look for solutions to already solved problems? Do we actually look for solutions or do we actually start building our own solution right away? How much do we consider the long term impact of writing our own codes and how much attention do we pay to it?

Potential future maintenance costs. So today I'm going to tell you a story of a Sloan train wreck that's waiting to happen in every fast growing software company. When growing complexity in software applications in software application architecture meets increasing requirements of a growing user base.

We have a problem. We have two trains first slowly, then later on accelerating towards each other. So let's talk about Train 1. Train 1 is your users. When we are building an MVP product in early stages, we very much so, we're always told to focus on one user, solving one use case. And that's what we do. We focus on one user, we make our system, it's very we make our system very easy to use for that one user.

And potentially we have one or two roles, super admin and read only. And the users of our system are not only our back end end users. We also have customer service, customer success users, our own back office. Again, we only potentially have one person, maybe one or two people from the founding team, handling all of the customer requests, dealing with customer you know, complaints or changes.

They have full access to the entire system. However This train is accelerating. As we start getting more customers, those customers start getting more complex. We start acquiring new users in new roles. And our customer success gets more complex because we now have a big system that we need to support in our back office organization.

We have customer success, accounting, technical support, and various other roles. So there is no more prototypical two user system with two user type, no prototypical single support user who can have access to everything. That means we now have multiple users in multiple roles that need to work together in order to complete a workflow.

And there comes the complexity of authorization. So let's take a look at train number two. Again, this is when we are building our MVP application. It's a very simple stack. We have a very simple stack every there's only one of every layer. It's a very simple architecture and Because as a business we are very much so focusing on making our business our product work Rather than scaling or anything else Everything uses the same language We don't have multiple microservices.

Everything is embedded. We use the same framework front and back end the same everything same because we are focusing our secrets sauce work. However, when the secret sauce works. We turn our technology into a product, our product into a business, and the natural thing happens. Naturally, we have a product, product footprint that starts growing.

This is an example of what all the microservices that are running Uber looks like. It's no longer a single stack, there is a service for every single thing. And so what does this mean? We have a front end technology. We have a back end technology. They communicate via APIs. We have a data team. We have a data science team.

We have an, oh, I wasn't supposed to use this word, but an AI team. All of these teams want to use different types of technologies and as leaders, we want to empower them. We want to make sure that they are able to use all for all those products, all those different technologies and from a simple framework.

Now we have a second train accelerating towards the first one. And our business growth dictates that these things will probably happen at the same time. They will both accelerate at the same time. The business is exciting. Everything we have within our system is growing. But from a tech debt perspective, it feels like it rains when it pours.

Sorry, it pours when it rains. And, in reality, it's a positive side effect of a good system, but there are lessons we can learn from this. We can actually avoid this train crash. Steve Jobs once famously said, innovation is saying no to 1, 000 things. And in order to prevent this train wreck in our organizations, we can actually pick our battles ahead of time.

We can you know, in any given business, there are actually more than two trains accelerating towards each other. There are many other functions, but I'm actually picking these two because, again, within the context of authorization and user permissions, that's the most valid one. And as businesses, we sometimes ignore this upcoming train crash, and that we are told that, because it's not directly linked to our revenue generation.

We know it will turn into a bigger headache, but We just kick it down the road, but down the road, what's expecting it? What's waiting for us? Our compliance issues, security issues, data leaks and all set of trouble. And there is a solution to this building smarter, but not harder and building smarter in this context is about leveraging what is out there already to solve our problems.

So for a second, I want to go back to the source of why do as a developers we always have an attitude. that says we can build that. It comes from a good place. Because in the past, in the absence of good things, in the absence of tools, software and developer tooling, we built them. And as developers we say, I can build that because we can.

But let's take a simple example going back to 1960s. In 1960s on these computers, or maybe early 70s, if you wanted to build a software product You had to build every single layer of that product. There was no databases available for you to tap into. You had to build your own data storage mechanism. Then you built your data, we built our data fetching mechanism, then our application layer, then our communication layer, and everything else.

And going back to being developers, just given enough time and money, we can build things, but should we? So, throughout recent history, especially, there's been a big acceleration on building frameworks, libraries, libraries on top of libraries, and because this is what we do, as humans, we are one of those very few animals that can build tools to make our lives easier.

We can actually build tools from tools, and tools from those tools. To make everything happen, you know, take a look at any software stack. You're going to see it's whole set off, you know libraries that it takes advantage of and we build tools and we share them. We make them available. That's what we did at service.

We make authorization easy. We make it. We make it so that as developers, you don't have to create a core part off. Software infrastructure and just for clarity, what authorization is, it's not authentication. Everybody usually conflates these two author. Authentication is verifying who you say you are and authorization is whether you have access to a specific.

Thing. Take this conference, for example, we all have to show our identification to get our badges. Our badges define who we are, and then on those badges, we have attendee, alpha, alpha, beta, grow, and there's VIP, different labels. That dictates which rooms we can go into, and which room we cannot. And, so, we had to build this authorization software because there was nothing out there.

We were, we're one of those very true pioneers in enabling that for applications. And going back to Shane's presentation, the previous presentation we had to take, pay attention to these seven pillars, and one of them is great great developer experience, which I'm not gonna go into. I think we covered that pretty well.

But as well as simple, API Shane talked about how APIs should be very simple, easy to understand, easy to compress single functionality, and we had to pay attention to that when building our solution. We had to make our authorization solution fast because authorization is in the blocking path of every API call.

Any delay we introduce in decision making, whether a user is allowed to do something or not, introduces delay on user experience. It had to be secure. We're talking about security here, and we cannot have security without secure. And this is something that's going to run in the heart of your software.

It's going to be something that you're going to have to trust, and your entire security team has to trust. A developer, as a developer infrastructure tool, we wanted to make sure that something is extensible. Something that actually stands the test of time. And extensible also means it doesn't only address a single use case.

But as your use case grows, you can, as a developer, you can enhance it and make sure it also addresses those. And no tool these days, especially as a software layer, is a true tool that you can use if it's not scalable. We are very much used to scalability when it comes to A W S or other services that we find online.

But what does it mean in the context of security? It means making sure that whether you start one instance off this software or a million instances, you get the same response time. You do not get any performance degradation. And of course, any security tool has to be reliable. You need to make sure that tool is always up and running and always ready to answer your questions, especially in security.

When you ask if If you default to yes or default to no whenever your product is not reliable, it's not functioning, that causes major problems because insecurity saying yes to everything is as good as having open doors and no is as good as just shutting your application completely down and do not letting anybody use it.

And of course, all of this needs to be done on top of great developer experience. And why am I talking about all of these? Because these are the pillars that we should all use in order to be able to build the tools that we want to build. If we are not going to be able to pay attention to these tools, and we're not going to be able to grow with them, we're not going to be able to maintain them, probably we should consider getting something else in.

And we built this in Servos and we made it open source because we want to make sure that we're giving back to the developer community. Who may not be able to purchase premium services. Who may not be able to get good security into their product because it costs a pretty penny. We want to make sure that every developer has access to these tools.

I'm not going to talk your ear off about our products features. Please come and see us in pavilion three growth stage. And if you have any questions, we're happy to answer those. So just to summarize the moral of the story is. We believe that businesses should focus on their core business and do not reinvent the wheel, especially when it comes to security.

We build these security layers over and over from one company to another. There's a little bit of know how that's transferred over, but there's also a lot of loss. So building that wheel feels like reinventing it from scratch. And especially in an era where GDPR, CCPA, etc. exists. who do not cover their security bases may be exposed to catastrophic business failures.

So, my one ask is, let's not ignore the train crash, and let's, every time we have a temptation to build, let's second guess the temptation of, I can build that. Thank you very much.