We recently had the opportunity to chat with Dan Lines from Linear B about cloud-native authorization and why it is a major pain point for most organizations. Tune into Aserto CEO, Omri Gazitt, as he shares Aserto’s founding story and his tips for first time founders. He then shares a couple open-source tools you can use to help build your access control system, and what architectural patterns you should follow as you build it.

Listen to the podcast here or read all about it below:

The founder’s story

Aserto CEO, Omri Gazitt, has been working on developer and infrastructure technology for three decades now, most recently as the CPO of Puppet. Prior to that he was the VP and GM of HP's Cloud Native Platform (with responsibilities for OpenStack, Cloud Foundry, CloudSystem products), and a General Manager at Microsoft with responsibilities for Azure, SQL Server, Application Server, and the .NET Framework. Aserto is his third startup.

As an engineer founder, he believes that founders have to be optimists. They need to believe something that is counter intuitive for people who lead with logic. They need to believe that their company will make it, that they will go from zero to one, which is a very improbable event.

Here are a few tips for first-time founders:

1. Be fearless: Founders early in their careers, don't have fear. They don’t know what it's like to fail and that is an advantage. The more experienced you are, the more you've seen patterns, and the more you apply some of the wisdom that you've learned in other situations. You also might become a bit more realistic and that can take away from the magic. So stay fearless.
2. Remember why you are doing this: Why did you start a company? What are you in this for? There's nothing like tough times to make you ask yourself why you’re still doing it. Having a good answer to this question is really important.
3. Keep a sense of perspective: You don't want to get too affected by the highs or lows of a startup. It's great to celebrate successes, but remember that it's a marathon. You have to even things out.
4. Give it your all: You want to give everything you have as a founder, but know that there's only so much that you can control. An economic downturn isn’t under your control. A market that's too early, isn’t under your control either. Focus on the things that you can control.

The founding story

Let’s start with some context: People tend to lump identity and access control together and call it “auth.” However, these are actually two distinct processes. Authentication is the process of proving that you are who you say you are. Authorization then determines what you can access. In the context of an application, authorization determines what a user can see and do once logged in.

Back in the old days of operating systems, we used user IDs and passwords for authentication. These days, we use magic links, biometrics, and multi-factor authentication. But the process is basically the same: it's proving that you are who you say you are.

Authorization is downstream from authentication. Now that you’ve proven that you are who you claim to be, what can you do in the context of the software that you're logging into? What permissions do you have on those resources?

Going back 15 years, before the age of cloud and SaaS, business apps would talk to the operating system to figure out who the user is and what they could do. Authorization was managed by groups in directories like LDAP, or Active Directory, that corresponded to roles in the application.

Fast forward to today, authentication has successfully moved to the cloud. We have protocols like OAuth2, OpenID Connect, SAML and JWT, that have given way to an interoperable identity fabric. Companies like Okta have solved single sign-on for enterprises. And companies like Auth0 have made it easy for developers to incorporate authentication into their applications. So today, no one has to build login unless they want to.

Unfortunately, access control hasn't really moved forward at all in this time. There are no standards, protocols, or established developer tools for cloud-native access control. So every application has to go build its own roles and permissions and enforcement logic. This is why we founded Aserto.

15 years ago, Omri and Gert, Aserto founders, were working on what became Azure Active Directory. Back then they helped solve the identity problem which is pretty much solved now. However, access control is still very much a problem, and a hard problem to solve. It's a much more domain specific than authentication, as each application looks a little different.

Access control is one of those things that doesn't make your beer taste any better. It's the cost of doing business - you need to have it if you have a business application. But it's not differentiating your application in any way. It's toil.

Omri and Gert understood that if they built a set of authorization tools for developers, they could save them the hassle of building authorization systems, and help them build their systems correctly. They were motivated by how prevalent broken access control is. There’s a reason broken access is at the top of the OWASP top 10 list of security issues. The OWASP found some form of broken access controls among 94% of the apps tested in its 318,000 dataset. There's so much pain to go around: it's not just developers, it's security teams, it's IT teams. They wanted to solve cloud-native access control for all of them.

Cloud-native access control

One of the main challenges in cloud-native authorization is that every microservice is responsible for its own authorization. This tends to mean that every service authorizes differently, especially when small independent teams own each microservice. Things get out of hand quickly when every team implements authorization differently. You end up with a bunch of permissions strewn across different places, and spaghetti logic.

Thankfully, there are now a set of vendors that have encountered this problem and have written about how they solved it and built their unified access control systems. These include Google, Airbnb, Intuit, Carta, and Netflix. While the systems might be built differently, they all have the same architectural principles which we call the “5 laws of cloud-native authorization." Here they are:

1. Unified authorization service with a distributed systems architecture: all of the companies above have extracted their authorization logic out of each of these microservices and created a purpose-built authorization service.
2. Real-time access checks: rather than relying on OAuth2 scopes that are baked into access tokens for permissions, these systems make a call to the authorization service with the user context, resource context, and the permission before granting access. This way you can ask the question ”Does this user have this permission on this resource?” in real time, which is a much more secure practice.
3. Fine-grained authorization: you want to adhere to the principle of least privilege and limit the set of entitlements/permissions that you give to users to the smallest set they need to do their job. This goes against the old school idea of coarse grained roles and permissions, like “admin” or “editor” with permissions over every resource in the application. Rather than assigning coarse-grained roles each of the companies above is able to set specific permissions on specific resources, like projects or documents or folders.
4. Policy-based access management: you want to maintain separation of duties by extracting authorization policy out of the application and into the hands of the security team. The policy is stored and versioned independently and the policy is written in its own textual DSL. This is called policy as code. If you do this, you can hand over the authorization surface to the security team, who can reason about the different authorization logic across all your microservices. The ability to reason about your access control across services and applications is in itself a major accomplishment.
5. Centralized decision logs: gathering decision logs for every decision that the application makes will improve your security posture and enterprise forensics. These days, it’s not a question of if you will have a breach, it's a question of when. And it's not enough to know all the times that users logged into your app. You want to know everything your users did, every decision that the application made. These authorization decision logs help identify the “blast radius” of what was compromised.

Access control is one of those problems that's misleadingly hard to evolve. So you want to get it right from the beginning. And that means understanding these patterns and reading some of the literature on how some of the large technology organizations mentioned earlier solved access control.

It’s also important to understand that there are open-source projects out there that can help you get ahead of the game. If you start building with the right set of tools, you'll be able to extend a simple model like RBAC into a more involved model like ReBAC over time. So you don't have to accrue technical debt, you can start with a flexible framework that evolves as your needs change.

Topaz is one such tool. It’s an open-source project that uses Open Policy Agent (OPA) as its decision engine and comes with a Zanzibar-inspired directory, that allows you to relate subjects (users or groups) to objects (entities in your app like tenants or teams or projects or items or lists). It combines the best of OPA and Zanzibar to support RBAC, ABAC, ReBAC, or a combination of them, out of the box. Your policy can use the built-ins to find out whether this user has this permission on this object, or this user has this role for this tenant etc., without having to write very involved Rego policies.

Aserto is built on top of Topaz and adds a control plane that you can run to centrally manage users, policies, and decision logs. It provides a unified authorization system across applications and services.

Conclusion

Cloud-native authorization is hard. There are no standard, protocols, or established APIs for cloud-native authorization, forcing every application to reinvent this wheel. The microservices architecture adds to the complexity as every microservice is responsible for its access control, and essentially authorizes differently.

Thankfully, a few large technology companies with sizable engineering teams have written about how they solved this problem for their applications. And from these papers, we were able to distill five common architectural patterns that every cloud-native access control system should have. These “five laws of cloud-native authorization” include extracting the application logic from each service and into its own service, running real time access checks upon every request, providing fine-grained controls over application resources, treating policy as code and storing and versioning it separately, and collecting authorization decisions logs for auditability and enterprise forensics.

Topaz can help you get ahead of the game. It is stand-alone open-source authorizer that provides the best of OPA and Zanzibar. It supports every authorization model out of the box. You can deploy it in your cloud today to add RBAC, ABAC, and ReBAC to your application.

As always, we’d love to hear from you. Drop us a line, or join us on Slack!