Fine Grained Authorization, Open Source and Topaz

Damian Schenkelman: Welcome to another episode of Authorization in Software, where we dive deep into tooling standards and best practices for software authorization. My name is Damian Schenkelman. Today, I'm chatting about Authorization and Topaz, T- O- P- A- Z, an open source project for Authorization with Omri Gazitt, co- founder and CEO at Aserto, the company behind Topaz. Hi Omri. It's great to have you here.

Omri Gazitt: Hey, Damian. It's great to be here. Thanks for having me.

Damian Schenkelman: Yeah, really excited about this. We usually start asking folks to share with all themselves, so could you give our listeners a brief overview of your background and what you've been up to?

Omri Gazitt: Sure, yeah. I've been in the industry for now over 30 years, which is a little scary. I've spent pretty much my entire career building tools for developers. First at a startup where I was the founding engineer of, back in the very early'90's. I joined Microsoft in the late'90's, was very fortunate to help co- found the. NET project. Later on, the Azure project. Worked on a lot of the early web standards, starting with SOAP, WSDL and WS- Federation. That's where I met Vittorio and other people that were working on the very, very early versions of what became all the interoperability standards like OAuth 2.0, OpenID Connect, SAML and so on. Led the access control service while at Microsoft as the general manager of that and a few other things. Left Microsoft because I was largely frustrated by how little we understood open source. I felt like open source was a huge factor that we just completely missed. Microsoft spent the next 10 years working on open source like OpenStack, Cloud Foundry, the Kubernetes ecosystem and Puppet. Then Aserto is my third startup, started that in late 2020.

Damian Schenkelman: That's nice. As you say, you've been doing that dueling, you've been doing security, identity and you've been doing open source. This is a big reason why it's great to be chatting with you. We're going to dive deep into this topic. Let's get started. What is Topaz? What are we going to be talking about?

Omri Gazitt: Topaz is an open source authorization engine that basically combines some of the really interesting good ideas that we've seen over the last, maybe let's call it, three years in the authorization space. The first one is this idea of policy as code and the best representation of that today is the open policy agent project out of the CNCF. It's not the first one that's attempted to do it, but it's the largest open source ecosystem around that idea. The second idea is the opinionated line- created authorization model that we all read about in Zanzibar paper. Then the third idea is really the idea of doing authorization in real time. That is rather than trying to rely on scopes and access tokens that are minted at authentication time, the idea of separating authorization is a separate process that happens right before you want to grant or deny access to a protected resource. Those are the three things that really combine into tokens.

Damian Schenkelman: Yeah. Those are some of the big trends in the industry, I think. But real- time authorization is, " Hey, you want to make sure that you have the latest and greatest when you make any decision," a big part of that zero trust concept and then the whole ReBAC, relationship- based aspect with Zanzibar and policy as code. Those are the three big trends that we've been seeing as well. I think everybody working on authorization is kind of closely following. Now, before we dive deep, you have mentioned a few concepts. Some of them might be new to folks, some of them we've discussed in the past in the podcast. But when you say authorization engine, what do you mean? What makes an engine? Why is having an authorization engine important?

Omri Gazitt: An authorization engine quite simply takes inputs and produces an output. The inputs are typically subject or an object and some kind of policy, permission or some decision that you're trying to compute. The output is of course the decision and probably just as importantly a log of that decision. An authorization engine takes typically three inputs, user policy or permission, however you want to call it, and the resource that you're trying to perform an operation on and then gets back as a state, not allow it or deny decision.

Damian Schenkelman: Okay. From the outside, it's like this black box where I send it, who wants to do something, what they want to do and what they want to do it on. It replies whether they can and can't do it. Essentially, keeps an audit log of what happened, which is important for compliance reasons, security reasons and a few other things. Then you mentioned a few things like, " Hey, you can write these policies, these rules, in code that allow you to specify who can get access to what." That's part of your authorization model. Then you mentioned this notion of Zanzibar and how you can use stuff like this relationship- based authorization to make decisions, which we're going to dive deep into in a few minutes. But before that, what made you decide to implement Topaz? Why is this something that you say, " Hey, we need to do this, this is very important?"

Omri Gazitt: Yeah, that's a great question. I would say it goes back to our, first of all, we have pretty deep open source roots, my co- founder and I. When we first started Aserto, we looked around, we could get to why we even got to authorization as a problem. But when we looked around the authorization space, we saw OPA and we didn't feel like we needed to reinvent the wheel. There was an engine, the Open Policy Agent, it had defined the language. The language is not perfect, but it's there. We felt like we wanted to make that the basis of an authorization solution for application authorization. Because OPA was used a lot in infrastructure authorization scenarios. We felt like there was a vacuum in terms of solutions for application authorization. Very quickly, we realized that OPA had a pretty good story for policies, but it didn't really have a great story for data. For all of us that have been in this space for a while, we know that data is the problem. Because you're basically making authorization decisions based on data. With OPA, they're really two models. You bring the data to the engine when you make the call or you store the data along with the policy. We felt like neither model was very satisfactory. Because if you're storing the data with the policy, sure enough your data, you don't have that much and it's slow moving. Then maybe that's fine. But in application authorization scenarios, the policies evolve slowly and the data evolves very fast. The cadence of evolution is very, very different. We realized OPA doesn't have a data plane. We need to go build a data plane for OPA. We built that authorizer. Then as we continued down this journey, we realized there's actually a perfect data model for the data that we want to support in our authorizer, which is the triple store model, that basically Zanzibar is based on. We decided to combine these two really good ideas. We felt like there was no other open source project that combined these things in a way that was complimentary. Oftentimes in this industry, you hear policy as code versus policy as data. We felt like, " Hey, you could actually take the best of both of these things and combine them in an elegant fashion." That's what we hope we've done with OPAs.

Damian Schenkelman: Yeah, I definitely agree. I think there are instances where having your policies expressed as code, directly like using a policy language. It could be Rego. It could be SAML if that's your jam, or any other things like Cedar, which we did an episode on earlier this year. That's perfectly valid. There are scenarios for that. There are scenarios where being able to express things from a relationship perspective with the triple syntax that you're mentioning. We also did a couple of Zanzibar episodes, which we're going to link to. There are always ways in which you can find when it fits. Being able to combine these two together could be really powerful. But I think the key thing here is that as you're saying, the data is the biggest thing. That's one of the main things that at least I thought of when I started looking at this problem. It's similar to MapReduce. You want to bring compute to data, but you don't want to be moving data over every time you make to make a decision because this authorization decisions need to be fast. It seems that's one of the things that you folks are going for. What are the other design principles behind Topaz? What are the things that people will see and would be able to feel if they start using it?

Omri Gazitt: Yeah. The first one that you mentioned is a great one, which is we think that authorization has to be a local call over local data. Because you mentioned the executable architecture. I think I'm old enough to remember, in fact, my team actually participated in building the executable spec. The spec does a good job at laying out functional components. You have the policy decision point that is essentially what we call the authorizer. Then you have policy information points. The idea is that the policy decision point can reach out to the information point, grab some data that it needs for evaluation and then make a decision. That may be fine in the age of software. It ain't fine in the age of cloud, because basically these services that are downstream from you have availability and have latency. In the same way that you don't want to make an API call across the internet for every authorization request, because authorization is in the critical path of every application request. You don't want to take 50 milliseconds, 100 milliseconds of latency going, talking over the internet just to find out whether the user is able to do the next thing or not. You also have the same issue with respect to the data. We felt like the data has to be cached. That's why Topaz, if you look at it under the hood, it's really a set of things. It's OPA as the decision engine. We bring that in as a Golang library. It's an embedded store that's based on BoltDB. We basically store all the data and we demand load that data out of that storage as the policy needs it. We basically have a database architecture within Topaz. Then it has a set of API gateways, gRPC, REST and so on. Basically, making a decision call can be very, very quick. We typically benchmark decision calls around a millisecond. That's the architectural principle around making decisions quickly with local data. Then the other ones I think we've already talked about. We want to support all manner of fine- grained access control. We want to support attributes and relationships. We think both of them are important. We think the policy, it's important to be able to extract policy out of the application, store a version of it separately. We want to support that policy as code workflow. Then like we talked about, we have the real time aspect of it and the decision logs. Again, very, very important to maintain a log of everything that's ever happened. Those are the architectural principles that you'll find in Topaz.

Damian Schenkelman: Nice. Yeah, I think one of the things you said reminded me of a conversation I had a few years ago with someone which was, when you draw something in the whiteboard and you have arrows, what the arrow is very important. Is it a metal cord or is it a wire across the continent? Because those two things are going to make a big difference in whatever you're doing. It's not just theoretical. I see a lot of that in what you folks are implementing.

Omri Gazitt: Yeah. DCOM is case in point in that. Back in the'90's at Microsoft, we used to have this thing called COM, which was very successful as a way of sharing components between different applications. The idea of DCOM was distributing that. Very soon, we found out the difference between chatty interfaces and well- designed interfaces. Yep, nothing new under the sun.

Damian Schenkelman: Yeah, yeah, exactly. It's like fashion. It's cyclical. You mentioned this notion of fine- grained authorization. You folks started doing what you're doing in 2020, so three years ago. What's making fine- grained authorization important nowadays? It seems like it's a growing fast trend.

Omri Gazitt: Yeah. I think there's a number of things that are contributing to that. If you look at the macro trends, I think this notion of the parameter security is a thing of the past. We have this very overused term called zero trust, which I personally hate. But this idea that burden of securing applications has moved from the environment to the actual application itself, but the applications haven't really kept up. If you look at the 2021 auth top 10, broken access control is number 1. In 2023, they just published the API security top 10. Number 1, number 3 and number 5 are all different forms of broken access control. We know that this is a problem that's plaguing these applications. Now that at the same time, you look at the breaches that are happening and how devastating they are to those organizations, you end up with an imperative to adhere to the principle of least privilege. When you start looking into what that entails, it really means the status quo is not going to work anymore. This idea of over- provisioned roles that you grant all these people and you do recertifications every year. It's a manual, error- prone, soul- crushing process. I think people realize that there's got to be a better way. For us practitioners, we like to say, " We haven't had our OIDC moment," our OpenID Connect moment for authorization. There's this magical moment about, let's call it 10 years ago, where all of a sudden we had this critical mass of SaaS applications that supported a standard- based authentication flow. We had a critical mass of companies like Auth0 and Okta that provided organizations with the ability of building that very cheaply and easily into their organization. We just haven't had that yet. We look forward to the moment where the same thing can happen in authorization, where we don't have every application build its own authorization system and every application admin has to manage any of them. We look forward to the day where an N times Z problem becomes an N plus N problem. I think all of that is in its early days, but that's why I think there's a lot more focus on this.

Damian Schenkelman: Yes, I like how you use words that are more in the air, so to speak, to explain this concept. It's like, " Hey, these over- provision roles that you have, that will be the coarse- grained stuff." Then when you get into the principle of least privilege, which is like this file that's coming with the notion of zero trust, that will be very tied to fine- grained. No more than you need. How does Topaz implement fine- grained authorization? Again, this is a concept, but then what's your vision of how this should work and how are you making it happen?

Omri Gazitt: I think basically, we have a couple of ideas of what data looks like. For every organization, there's going to be common data. Things like users and groups are typically shared across all the applications, at least for internal apps. Then if you look at each application, it has application- specific data. We think that the right architecture is to be able to have shared concepts of users and groups and the ability to assign them as subjects across any of these applications. Likewise, we think that a lot of these applications will have policies that are a little bit more involved than just ReBAC policy. You could have an application that's entirely ReBAC or entirely attribute- based. But we find that most of the folks that we talk to, that may be selection bias because people find us that actually have more complicated models, but most people have this combination that they want to implement. That basically wants to reason about attributes about users, attributes about resources and relationships between them. We feel like a policy should be able to give you access to both these common things, like users and groups, as well as application- specific resources and the relationships between them. With Topaz, we've actually implemented, the store is not just a relationship store. It's a store that optionally allows you to go store concrete objects. Users, all their properties and potentially even objects. Now, where the line is between the authorization system and basically the line of business application database, that's a gray area. We like to tell customers, " Do not treat us as an OLTP store. Don't store all of your application data there." It makes no sense. " Only store the data that you need for authorization purposes." If it's just literally the key of the resource, then that's great. But if you need some attribute about the resource, for example, if a review has been submitted or not, that's something that's very easy to store inside of that the data store. You can then reason about not just relationships between a user and an object like a user and a document, but whether that document was also submitted. Make that both conditions necessary for making an allowed decision. That's really how we implement the best of both worlds, ABAC and ReBAC in the same system.

Damian Schenkelman: That makes sense. Let me see if I can map these notions to a company that's relatively large, might have a few services and a few apps. If I understand correctly, what you're saying is if you're working with different services, let's say you have a service- oriented architecture, to avoid the microservices term, each team would conceptually write policies that have their own business logic. These policies would be able to consume the users and the groups that are figured out through these relationships. Like a user belongs to a group and a group belongs to other groups. Those would be more global. It's not like each of those services would have their own notion of groups. It's more like shared user groups. Then the attributes and the policies are per service.

Omri Gazitt: Yeah. Basically, the subjects can be shared. An organization could define their own subjects too. They could decide that their departments are going to be organized in a very particular way. An admin now has a hope to basically say, " Okay, for this particular application, the way that we're going to do assignments is, we're going to do assignments to departments," for example. For example, this folder, everybody in this department has read access to this folder. That way, you could basically have an organizational principle on the subject side that can span multiple applications. I think that's a big unlock in terms of starting to make it easier for admins to have a single control plane for the subject in the system. Now, objects are going to be applications specific. Every application will have its own model. For us, a model consists of both rules in the policy, as well as essentially a manifest for our directory. You'll define your object types, your relation types, your permissions in an application specific fashion so every application has its own version of that. But it can basically assign as the subjects, it can assign all of these shared constructs that an organization sets up. We think that that starts taking you down the path where instead of M times M, you can start collecting these common things.

Damian Schenkelman: How does an implementer or a developer decide whether something should be an attribute versus a relationship? You mentioned the notion of a department. When is a department an object that is related to the user versus when is it an attribute of the user of department, HR or something like that?

Omri Gazitt: Yeah, that's a fantastic question. I think it really is for many of these things, it's a style choice. Many people that come from an attribute world would immediately say, " Department's an attribute." For us that have been in the relationship world, we think of that as a relationship. There are some cases where it's a little bit more clear cut. For example, there may be a set of statuses on a piece of data that you don't want to create a relationship for and have to move an object. You remove one relationship and add a different relationship. Those tend to be unions and software speak, so to speak. But there are a lot of things that I think it's a judgment call. I think for things like organizations, projects, teams, those tend to feel more like relationships. For us, managerial relationships are obvious. You have a user graph. One of the things that we focus a lot on is exposing, being able to import data about not just users, but also management relationships. Typically in policies, you want a transitive type of relationship. If for example, someone owns a document. In a lot of organizations, their manager should have at least read access to that document. That may be true in insurance industry, for example. Where a manager of some insurance office has access to the policies that their reports are writing. Those are very standard types of things. Those tend to be transitive relationships that are much better to express as relationships than as attributes. Then the last thing I'll say is there are some things that are really hard to do as relationships. For example, any type of calculation where you're trying to figure out whether somebody has an approval limit, above a certain number or below a certain number, and compare that to an attribute of, I have an invoice, as an approver I can approve invoices that are under 50, 000. That is an expression. Those expressions tend to be expressed more as rules as opposed to as relationships.

Damian Schenkelman: Yeah, that makes sense. That's a very detailed answer. I think in general, anyone implementing authorization would benefit from that one. We've been talking a lot about relationships. The Topaz documentation mentions this notion of, I'm going to use air quotes, although no one sees it, " Zanzibar directory." We've talked about this Zanzibar thing in the past, but what is the Zanzibar directory specifically in Topaz? How is it different from Zanzibar and the paper? Why did you decide to make those changes?

Omri Gazitt: Yeah. I think the idea of a triple source is not new. It goes back at least as far back as the RDF model and the semantic web. We basically set out to build something that expressed the ability to express the relationships between subject and objects. Also, be able to optionally store these concrete objects. Different implementations are different. But we chose to have, for example, a table for objects, not just a table for relationships. In that way, you could say that we've extended upon the core idea of just storing relationships. A lot of the core of the Zanzibar paper is expressed at least in terms of the model. This idea that our model underneath the covers is able to express different operators and things like that. We've been in the process of implementing more and more of these operators, but the idea of being able to express these relationships and evaluate them transitively, that's all in there. Some of the things that we chose not to focus on that are in the Zanzibar paper, most notably Zookies. The consistency guarantees. Not to say that that's not important for some subset of applications, but just when we talk to our prospects and customers, their experience is so crappy today with respect to consistency. They basically say, " Look, here's the world I come from. I have an access token. The access token has time to live two hours. For the most part, once that access token is minted, any changes on the backend have to wait until that token expires." Yeah, we know that there are certain revocation types of things, but that's really state- of- the- art for us right now. Our latency between when something happens in the backend and applications end up sensing it is typically measured in hours, not in seconds. The fact that you can get to consistency in a second, that's amazing for us. We've found that while there are probably some applications that could benefit from a total causal ordering between these types of events, even the folks that built Zanzibar, Abhishek, over at Google famously came back and said, " Hey, we invested in that mechanism and maybe under invested in developer experience." That does come up for people who are very, very familiar with Zanzibar. They ask us about whether we have support for Zookies. We said, "No." That can be a differentiator for other people who've actually built that. But for the most part, the vast majority of people don't care necessarily about that mechanism.

Damian Schenkelman: Yeah. I think it's good that you mentioned that. I think it's an interview that Abhishek did with Oso or something like that where he shares that.

Omri Gazitt: Yeah.

Damian Schenkelman: In general, I think it's because the paper mentions the word Zookies so many times that it became so relevant. Then as you're going to flake, the more time you spend thinking of the problem, the more you realize that if you can keep the system convergent in very small amounts of time, it works for a great, great number of problems. Another thing that I always think about, and this is a less popular paper. Facebook had this paper, I think it was in 2013, about TAO, their authorization system, which is like this graph. It's definitely eventually consistent. They came up with this other paper. I think it was like eight years after that. If I remember, it's going be 2021, called it RAMP- TAO where they added some of these stronger guarantees, not exactly Zookie like. But if it took Facebook those eight years for some of their teams to need it, it's that most folks don't really need it.

Omri Gazitt: Yeah. We've talked to very smart teams that have read the paper. They've looked at our software. They were trying to figure out whether they're going to build their own or use something else. They asked us about it. We say, " We decided not to build that mechanism." They're like, " Oh, okay, good, because we were thinking about building, but we didn't think we needed it. We're just trying to figure out whether we're smoking something." There's definitely one product I'll have to give them the props here, Spicy Bee that's implemented the Zanzibar paper pretty much to the letter of the law and has improved upon it. I think they've done great work. We just felt like that's not the approach that we're trying to pursue. We're not trying to be the most Zanzibar of all Zanzibar implementation. What we're trying to do is just be very pragmatic as a small team in prioritizing the problems that people are asking us about. For us, for example, the problem of getting data into the authorization database is a much more pragmatic problem. That's where we've decided to spend a lot more of our time than in the consistency guarantees that frankly not very many people ask us about.

Damian Schenkelman: Yeah, that makes sense. Talking about that, what data sources does Topaz support? How do you folks, first of all, decide what to prioritize? But also, what do your users typically ask about?

Omri Gazitt: The most obvious piece of data or type of data is users and groups that come from identity providers, the like and directories. We've basically built a framework we call ds- load. It's a very engineering type of name. But the idea is that it's essentially an ETL type of process where you have a set of plugins that we built, but anyone can build. That extracts data out of the source. Then we transform it. We give you a lot of control over that transformation. It happens to be using Go templates. Then we load that into the directory. We've created a pipeline for being able to do that. You can run that pipeline. Ds- load is an open source tool. But we've also assembled it in reasonable ways in our commercial product. We built plugins for obviously things like Auth0, Okta and Azure Active Directory, Cognito and Google Workspace and those types of things like Workday is a great source of data for relationships between individuals. The idea is that you can basically extract data from one source and also augment it with data relationships from other sources. It's a pretty cool framework for being able to get the authorization data into the store, where it's basically going to be used for authorization decisions. Most of the time, folks tell us the authorization system isn't the source of truth for user information or group information. That's pretty obvious. It's going to be an extract database. Part of the magic here is being able to wire into the various mechanisms to be able to use eventing systems to be able to push data down from the source into the extract database that we store in Topaz.

Damian Schenkelman: Yeah, that ETL process and particularly inaudible, merging these different sources is probably very valuable. One thing I'm curious about is, I imagine deployments of Topaz have multiple instances of this running, where you might have different nodes with their own database, BoltDB. Does the ETL process end up communicating with all of them? Is there some coordination mechanism between these nodes as the ingest data? How does this work?

Omri Gazitt: Yeah. We're very flexible with respect to how Topaz instances end up reaching their data. There's a gRPC interface between the authorizer and the directory. By default, a Topaz talks to its local BoltDB. It can also talk to a Postgres- backed directory that can stand up as its own microservice in your cloud, close to where the authorization is happening. Then we have a control plane. The control plane basically acts as a signal so that all the Topazes that are connected to the control plane, as soon as new data is available or new policies, the control plane will send them an event over a net bus and the Topazes will download new data into their BoltDB if that's how they're configured. There's a lot of flexibility in terms of how you want the actual data architecture to work. For some organizations, they want to have all the data in their cloud. They don't want to have it leave at all. Other organizations want to have the data. It's essentially being sourced in the directory. Then they'll want to make changes, add, remove objects, change objects, add relationships, remove relationships in one central place. Then they want our control plane to distribute all of that to all the Topaz authorizers. It is truly and eventually a consistent model. If people value consistency above all, they can basically have a single relational database backed directory that sits on their side that they can scale out. Then all the Topazes are basically stateless with respect to that. Both models are supported.

Damian Schenkelman: I see. That makes sense. It's like a spectrum. Pick your own adventure kind of thing.

Omri Gazitt: Yeah. Architectural flexibility I think is very important. We found that different types of organizations prefer different things. We try to be as flexible as possible in terms of making these things into components that they can just assemble in the right way.

Damian Schenkelman: Yeah. Authorization is very involved in the architecture of these systems. It's not like this external component that there is one flavor that fits all, that you really need to adapt to each of these architectures. We've been talking a bit about how to get data into the system. What about the data that goes out of the system? Particularly, in this very valuable log outputs of every authorization decision, where can you send them? How long does it take? What information is available there for every Topaz log?

Omri Gazitt: Yeah. Like you said, outputs are just as important as the inputs. The decision log stream is very important for things like compliance and forensics. We basically, by default, Topaz will collect decision logs, but store them on a local file. Then if you connect the Topaz instance to the control plane, we'll basically queue them up using exactly, once in order, a semantics. Again, using that and push them up to the control plane where the control plane will basically aggregate them together per policy. Essentially, every policy which corresponds to every application will have a complete stream of the decision logs. We offer streaming APIs and batching APIs to be able to get that into your logging system. For example, we have an ELK integration where you could basically set up a Logstash pipeline to be able to tap into the stream and then get the data into your ELK stack.

Damian Schenkelman: How does Topaz typically integrate with the system's architecture? How is it deployed? Is it a Kubernetes thing? Do you have templates for it? Does it run as a plugin in the cloud environment? What are the flavors that folks have available for them?

Omri Gazitt: Yeah. The most easy to consume is just a container image. Topaz comes as a container image. We have a CLI for it that basically makes it easy to obtain it. Then run it, start it, stop it, configure it and things like that. But ultimately, Topaz is a binary. We compile that binary. It's a Golang binary, so we compile it for the x64 and Arm64, Linux, Darwin and Windows flavors. We have customers that are actually just running the binary on a VM, because they have that kind of environment. But most people are essentially running Topaz either as a site or as a microservice in their Kubernetes cluster. That's the most prevalent deployment architecture.

Damian Schenkelman: Yeah, that makes sense. What about teams that don't want to run this themselves? I guess, some folks are like, " Hey, can somewhere else do it for me?" What alternatives are there?

Omri Gazitt: We believe that the right architecture is to run the authorizer locally and then to have us run the control plane. Some customers wanted to run the control plane or portions of it on their side of the cloud. Like I said, we're very flexible with respect to that. There are some people that love the fact that we have a hosted authorizer. That we make available for every policy that you basically, policy instance that you create with us, we'll automatically spin up a hosted authorizer. It makes it super easy to get started. You could literally just start interacting with an authorizer that's running a policy without having to deploy anything. Getting up and running for a developer is like five minutes or your next one's free, as I like to say. But ultimately, we don't know of any organizations so far, at least of our customers, that has decided to run their production workloads against our hosted authorizer. Now, that's not to say that we don't have good availability. Probably we've achieved around 99. 95% availability over the last year for our hosted services. But we still think from a latency perspective, most applications are latency sensitive enough where they want the authorization budget to be measured in milliseconds as opposed to tens or hundreds of milliseconds. That's why we've made the architectural choice to strongly advise our customers to deploy the authorizer close to their app. But the control plane, we can operate completely for you as a user. We have some organizations say, " Look, no data can ever leave our premises. We want to run an air gap environment. We have our own container image registry. We have our own database systems. Everything has to run locally." Fortunately, the system is built in a way where people can go deploy that as well.

Damian Schenkelman: That makes sense. If I get that, you can either host everything yourself, both Topaz data and control plane. You can say, " Hey, I want to run Topaz in my environment and then use Aserto as a control plane, the cloud service." Then you could say, " Hey, I want to run everything with Aserto." Essentially, you could manage things on the customer cloud completely, correct?

Omri Gazitt: Yes. Yep.

Damian Schenkelman: Beyond what Topaz provides, are there things that Aserto, the cloud products, gives customers that they wouldn't have available if they just went with the open source version?

Omri Gazitt: Yeah. I think basically the deployment flexibility that I talked about. The scalable Postgres- backed directory, that's something that we provide for commercial customers. We have deeper integration with data sources that is built around like that signaling mechanism that I talked about. The idea that new policies are, as soon as they become available in a policy registry, they automatically get synced to the Topazes. That's something that the commercial product provides. That's not available in open source. In open source, you just basically have a timer. You can configure that timer, but it basically will go pull the container registry to find a new policy image. When it's available, it'll go download it. I would say a lot of the optimization work that we've done in terms of signaling, handling data, collecting decision logs, aggregating decision logs, the policy is code workflow. We have an automatic way to help you create a GitHub or a GitLab repo and install a set of actions that builds a policy into a container image, assigns it, pushes it to a container registry and then all the signaling mechanisms. All of that stuff is in the commercial product. The decision log aggregations, the commercial product. You can completely use Topaz standalone. It works like awesome. It works like a champ and a lot of people do. But then there's a lot of heavy lifting to do to actually make that scale for our organization. We think that that's where our commercial product can really come in handy.

Damian Schenkelman: Yeah, that makes a lot of sense. This is where a lot of products in this space are. There's some version of open source and then when you feed out either the deployment model or hard to get data in and out of it, a lot of this similar to syntactic sugars in languages. If you want the niceties, you typically go with the hosted version. It makes things a lot easier for customers. This has been a great deep dive, Omri. I really appreciate your time. Is there anything else that you would like anyone listening to know?

Omri Gazitt: First of all, I really enjoyed the conversation with you as well. It's awesome to be able to talk to somebody who's so deep into the space, having founded your own project there as well. You guys have done some awesome work with OpenFGA. I think we're all learning from each other. We all have one shared goal, which is get this sorry state that we find ourselves in with respect to authorization and improve the state- of- the- art for the industry. Because it's just so important. Today, it's still, I would say, nowhere close to where it should be in terms of being turnkey for developers to be able to go build something that's undifferentiated heavy lifting, yet everybody has to go build their own. I'm very happy that there's so much attention to this space now from large companies like Amazon and small companies alike. It's been great to be part of that ecosystem. We're looking forward to helping folks move forward. Of course, if you're interested in what you've heard, come look us up. We have a community Slack. We're very friendly there. If you go to aserto.com/slack, that's where you can find us and how you can join the community.

Damian Schenkelman: Yeah, great call to action. Again, you should definitely check Aserto and Topaz out if some of the things that we've been talking about makes sense. I absolutely agree. I think we are at an inflection point for the authorization space. I'm really very glad to be able to cover some of that in the podcast as well. Again, thanks Omri for your time. We'll stay in touch. Wish you continued success in what's coming.

Omri Gazitt: Thanks, Damian. It was a pleasure and looking forward to staying in touch.

Damian Schenkelman: That's it for today's episode of Authorization in Software. Thanks for tuning in and listening to us. If you enjoy the show, be sure to subscribe to the podcast on your preferred platform so you'll never miss an episode. If you have any feedback or suggestions for future episodes, feel free to reach out to us on social media. We love hearing from our listeners. Keep building secure software. We'll catch you on the next episode of Authorization in Software.