We recently had the opportunity to join Brett Stapper on the Category Visionaries podcast, a podcast that explores the visions for the future of founders who are on the front lines building it. Tune into Aserto CEO, Omri Gazitt, as he shares a bit of his entrepreneur journey and why authorization is the next IAM frontier. Listen to the episode here, or read about it below.

Building the future or application authorization

Brett Stapper:

Welcome to Category Visionaries. In each episode, we speak with a visionary founder who's building a new category, or reimagining an existing one. We learn about the problems they solve, how their technology works, and unpack their vision for the future.

Let's dive into today's episode. I’m here with Aserto co-founder and CEO, Omri Gazitt. Omri, why don’t you share a bit about yourself?

Omri Gazitt:

I started my career back in the early ‘90s as a founding engineer of a startup called NEON Systems. We built middleware that connected the emerging world of Windows and client server applications with enterprise data sources. It went public in the late ‘90s and I've been going back and forth between large companies and small startups ever since.

After NEON I joined Microsoft and helped start the .NET and Azure projects. I was the general manager of the Azure application server division, and helped start what became Azure Active Directory. I left Microsoft about 10 years ago and have since helped build open-source projects the likes of OpenStack, Cloud Foundry, Docker, and Kubernetes while I was at HP running the cloud division. Most recently I was the Chief Product Officer of Puppet. And two years ago I founded my third startup, Aserto, to focus on application authorization.

Brett Stapper:

You spent 13 years at Microsoft. If you had to choose one big takeaway what would that be?

Omri Gazitt:

Microsoft is a very, very well run company. I've worked at a few companies during my 30 plus years of my career. In the end, it's a very well run company.

One of the things that you get to do at Microsoft is influence the lives of many people. And one of the things that you start to realize is that nothing you do matters. You could take most of the engineers out of Microsoft and the company would still run the way it does. It would take years for the company to feel that. That's one of the reasons it's frustrating to work at a big company. It’s nearly impossible to connect the work you do to the progress the company is making.

Brett Stapper:

That's what I hear from a lot of the founders on the podcast. They share a very similar experience. When they're one of a hundred thousand employees, it's hard to find meaningful work.

How would you compare your time at HP compared to Microsoft? What were some big differences?

Omri Gazitt:

The Microsoft that I joined was still led by Bill Gates, who was visionary enough to create the software category. He definitely did, before VCs became an industry. He also had a profitable company from nearly day one, which you don't see today. Back then, the company was still at the top of its game. When I left it felt like it had lost its way a little. It was an enormous company that was used to being a dominating power in everything it did. But there were definitely a few things that it missed, like mobile and even cloud to some extent.

HP was in a completely different mode. When I joined, I had the opportunity to work with Meg Whitman. The company was in a turnaround and she wanted people who were not afraid to roll up their sleeves and help with the turnaround. At that point HP was much weakened compared to how it was in its heyday, when it was a real force.

Back then, it was an engineer's company. In the 2000s and 2010s, it stopped being an engineer's company. That was an enormous difference, because Microsoft was very focused on product and engineering. When I joined HP engineering had taken a backseat.

Brett Stapper:

You mentioned that Microsoft created the software category. From your perspective, were you aware that was the company's mission back then? Was category creation talked about internally in those early days?

Omri Gazitt:

I think Microsoft started with the premise of creating that category in ‘75, and by ‘85 it was clear that it was working. Microsoft was growing quickly as a software company. The prevailing wisdom at the time was that you needed to build the hardware and software together. Microsoft clearly proved that you don’t.

Microsoft went public in ‘86. I joined in ‘98 and by then it was clear that our mission had gone beyond a computer on every desk and in every home. We were trying to become the dominant force in server software and starting to break into the enterprise.

The company reinvented itself in 95 or 96. Gates realized that the internet was the next big thing and that Microsoft was slow to it. So he mobilized the entire company to rebuild Microsoft as an internet company. That was heroic for the time. Microsoft tried to do the same thing in the 2000s, but it wasn’t until Satya Nadella came in and focused the company on cloud and devices that it really took off again.

Brett Stapper:

Fascinating. Now, two questions to better understand what makes you tick as a founder and entrepreneur. Apart from Bill Gates, what CEO do you admire the most and what have you learned from them?

Omri Gazitt

Bill Gates tops my list, because I've had the pleasure of being able to interact with him at Microsoft and work with him a little bit.

Steve Jobs is up there as well. A very different person. His 2005 Stanford commencement address, where he asked “what would you do if you only had one day to live,” was a huge influence on me at the time. I felt like that was one of the reasons I left Microsoft, to stay hungry and stay foolish.

Brett Stapper:

What about books? Is there a specific book that's had a major impact on you as a founder?

Omri Gazitt

To continue with the theme, Walter Isaacson’s biography of Steve Jobs certainly helped me cement the conviction that I needed to leave Microsoft. I consider Clayton Christensen's book The Innovator’s Dilemma required reading to understand the dynamics of why startups can beat larger companies. The Lean Startup by Eric Reese was also an influential book.

Brett Stapper:

Let's switch gears and talk about Aserto. Can you tell us the origin story behind the company?

Omri Gazitt:

15 years ago I started working on what became Azure Active Directory. I was the general manager for the Azure Access Control Service. At the time we basically had two directories in the world. LDAP, which was the Linux directory, and Microsoft's Active Directory. Active Directory had around 95% market share. It was the lynchpin of the Windows Server franchise.

Everything seemed great. But at the same time we realized that the new apps were going to be written as SaaS applications. That was pretty clear even back in 2008. It was also clear that authentication and authorization were going to have to move to the cloud, because there's no operating system to ask “who is this user and what can they do.” So my team worked alongside the rest of the industry to create standards, like OAuth2, OpenID Connect, SAML, and JWT.

Now we’re 10 or 15 years later and no one thinks twice about authentication. You have companies like Okta and Auth0 that provide SSO solutions and developer tools for building authentication. No one needs to build log-in, unless they want to. It's a solved problem.

However, the downstream process of authorization is a problem that is far from solved. Authorization is the process of determining what an authenticated user can do in the context of the application. And that hasn't moved forward at all in the past 15 years. So in 2020, my co-founder and I decided to solve the problem of authorization and Aserto was born.

Brett Stapper:

Why do you think the authorization problem has not been solved yet?

Omri Gazitt:

First of all, it's a more domain specific problem than authentication. You only have so many ways of authenticating. You can use user IDs and passwords, single sign-on, magic links, multi-factor authentication, or passwordless measures. But the protocols underneath are all mostly the same.

Authorization is domain specific. You want to be able to define a set of entitlements and permissions that are specific to the application. Every application has different types of objects: a candidate tracking system may have candidates and job descriptions, and a todo application will have a todo in a list or board, for example. You want to be able to allocate permissions for particular people or groups on the particular object types in your system. There aren't any standards for that.

Brett Stapper:

I was reading about the five principles of authorization. Could you talk us through some of those?

Omri Gazitt:

The principles of authorization are a set of patterns that we've observed in organizations that have solved the authorization problem. Google described this in their Zanzibar paper. Intuit, Carta, Airbnb, and Netflix all wrote about how they built their centralized authorization systems.

We have observed the following five patterns in all of their systems:

1. Unified authorization service with a distributed systems architecture: Authorization is on the critical path of every application request, so the authorizer has to run locally. You don't want to have to call a web API that's sitting a hundred milliseconds away from your application for every request. With that said, you want to manage all of the artifacts used for authorization (users, resources, relationships, and policies) centrally. So you need a distributed systems architecture. This is one of the reasons why authorization is a hard problem that hasn’t been solved yet.

2. Realtime access checks: There's a common anti-pattern where permissions associated with a user are baked into an access token that's minted by the authentication system. These tokens are good for hours or days. This is a terrible practice because you cannot revoke those permissions until that token expires, even if you want to.

What you want to do is make a call to an authorizer with the user context and the resource context and get an answer in real-time. To perform real-time access checks utilizing a distributed systems architecture, we need a smart caching layer. Systems like Google’s Zanzibar and Intuit’s AuthZ are optimized for computing access checks with local data that is cached at the edge. Changes to the inputs (subjects, objects, and relationships) are performed centrally and then relayed to the edge, so that the locally cached data is invalidated and refreshed.

3. Fine-grained access control: You want to move from coarse grained roles to fine-grained permissions. It's not enough to say that a user is a “viewer” of this tenant. You want to make that user a “viewer” on this particular folder, or that particular document. You want to be able to assign the lowest level of permissions, and no more than that. That's what we call the principle of least privilege.

4. Policy-based access management: You want to extract the authorization logic out of the application, and store and version it separately as code. This promotes the separation of concerns and enables independent evaluation of the policy.

5. Centralized decision logs: Decision logs capture every decision made as well as the inputs provided (user and resource context). You want to centralize your decision logs to to follow the principle of comprehensive monitoring. Anomalies in granted access can be detected and investigated much more quickly when the decision log data stream is gathered and centralized consistently.

Brett Stapper:

Now let’s talk about adoption and traction.

Omri Gazitt

There are two categories of organizations that find us valuable. The first is B2B SaaS vendors that want to move from coarse grained authorization to fine-grained access control. Typically their customers motivate them to look for an authorization vendor by asking for more granular control over their resources.

The other category is enterprise companies that want to create a common authorization control plane for a number of their applications. They have a consistent set of users and groups, and want to be able to assign permissions and roles to these users across a number of applications that they build in a common way.

Being that these days every application builds its own authorization system, it is impossible for them to manage access control across applications. They have to manage the cross product of users and applications, which is an enormous management burden. They want to simplify that with a single platform where they manage all those entitlements.