In the ever-evolving landscape of technology and software development, certain initiatives stand out as pioneers, shaping the industry with their invaluable contributions. In the identity and access space these include authentication standards such as SAML and OpenID Connect.

In this insightful conversation with David Lee and Sameer Sait, Aserto CEO, Omri Gazitt delves into the current state of modern authorization and the driving force behind Topaz and Aserto.

Tune into this episode of Identity Jedi for more, or read all about it below.

David Lee:

Tell us a bit about yourself, Omri.

Omri Gazitt:

I started in the industry as a founding engineer at a startup, in the early ‘90s. It was incredibly lucky to be at a place where I was literally the first developer, and seven years later we went public. I learned a ton about what it meant to build software.

I joined Microsoft in 1998 when we were thinking about new platforms. I had the privilege and luck of being one of the co-founders of .NET at Microsoft. I ended up running the App Server division at Microsoft and helped start Azure Access Control Service, which led to Azure Active Directory, as well as other enterprise services in Azure.

I left Microsoft largely because I was really curious about open-source. I moved on to work on OpenStack and Cloud Foundry, where I was a board member, and helped incorporate both into HP's cloud platform. I was the SVP of the cloud native platform team and then worked on Puppet as the Chief Product Officer.

The last 12 years were spent on open source, mostly building software for developers. And at least half of that has been building software in the IAM space. My teams helped develop SOAP, Web Service Security (WS-Security), and Web Service Federation (WS-Federation), which led to the OpenID and OAuth2 identity standards.

David Lee:

What led you to found Aserto?

Omri Gazitt:

I've been building developer tools for a while. I'm a developer. I understand developers, so I build software for developers.

Back in late 2020, I decided that it was time to do something new. I wanted to found another startup (Aserto is my third) and I was searching for something that was hard to do as a developer. My search took me 15 years back to identity and access. We started that journey a while back at Azure and it was just amazing to see how far the industry has come in terms of solving single sign-on for SaaS apps. We actually started Azure with a focus on access control, but quickly realized that we cannot solve access control without first solving the problem of identity.

Back in the 2000s, every SaaS app built its own login and had its own user ID and password. It was a nightmare to manage, especially if the business had a growing set of SaaS applications. If every app has credentials, how do we ensure that only the people that still work at this company have access?

As a result, the industry established protocols around identity, and companies, like Auth0 and Okta, were founded largely because the opportunity was ripe to build a solution for developers and solve the problem of login. Fast forward to today, no one thinks about building login from scratch, and identity is mostly a solved issue. Authorization is far from that.

When I talk to people about the level of pain they experience from authorization, every VP of engineering and CTO I speak to says that building permissions feels like a never ending pain, something they always have to go back to to tweak or improve. They need it because their customers demand it, or auditors require it. It doesn't add any value or differentiation. They wish some vendor would do it for them.

My co-founder and I felt like there's a real opportunity to do something that we know about, which would help developers build secure software without having to write everything themselves. There’s also a real business problem. Enterprises have a multitude of applications. They have N employees, M applications, and need to manage the cross product of the entitlements. That's manual, error prone, soul crushing work. It’s the type of thing that software can actually help solve. That was our motivation.

My co-founder and I have been working together for a long time, and ironically we collaborated back in the early Active Directory days. We decided to start a company with the goal of fixing broken access controls once and for all. We aim to provide developers with a tool to implement fine-grained authorization, so they don’t have to build their access control systems from scratch.

David Lee:

Sameer, from a CISO’s perspective, what’s your view on developer tools and developers deciding which authentication and authorization tools to implement?

Sameer Sait:

I think that the first step is not to mandate what developers need to use, because it's their job. They want to find productivity. They want to make things easier for themselves. It should really come from them. We can have a security engineering team that has a good relationship and partnership with the application developers, and advise them on the security aspect of things.

I think the second step is when it comes to budgets. I've never had a larger budget than a CTO, it's always smaller. So building that relationship early on where you say “I'll go to bat for security spending, but you're the one who's going to use it” is crucial. As long as the developers are willing to use it to secure our assets and keep us out of the news, I’m willing to pay for it. So I like where Omri is going with developers thinking securely, and having patterns or templates to work with.

In fact, I would argue that the more tools or technologies that we build for the rest of the world to think securely, the better. I think CISOs would love to see tooling or capabilities that make their life easier, not necessarily show them more findings.

Omri Gazitt:

Yes, exactly. To that point, I recently spoke at the OWASP Global AppSec conference about fixing broken access controls. Broken access controls is the #1 risk on the OWASP top ten list of application vulnerabilities. For that reason, it’s a shared interest between developers building applications and security teams. I gave a demo of an app with a broken access control vulnerability, and showed how you systematically fix these issues, and the audience really appreciated it. The vast majority of them were not developers, but rather security professionals.

As a CISO, you can buy tools to be able to detect some of these things. But you can't auto fix them. These issues typically stem from logic errors inside of the authorization code. So we need developers to understand the issue, and provide them with the right tools to succeed. We need to create a situation where the best and easiest way forward is the most secure way forward. We need to give developers the right tools to allow them to build authorization correctly, and make it easy to build it correctly. That's how we eliminate this problem.

David Lee:

We build software to replace the activity that we're trying to do. But I find it interesting that in security and identity and access what we ended up doing was create products that allow us to make more money. Products that don’t entirely solve the problem, but require users to continue and build on top of, or take additional actions to solve the problem.

Most developers are good developers, but not necessarily great security people. They don't care to be security professionals. And I’ve always viewed authorization as somewhat of a distraction to developers. So if we want developers to build access controls in the most secure way, we need to provide them with the tools that allow them to get to the desired outcome. If we tell an application developer to go build it themselves, we can’t expect them to build the most secure or comprehensive authorization system

Omri Gazitt:

We find that one of the big challenges with authorization is getting that architectural pattern or externalized authorization to be better understood. If we look at authentication, it wasn’t until the protocols matured and SAML and OpenID Connect emerged, that companies like Auth0 and Okta created externalized authentication services that developers could call instead of building everything from scratch.

We’re now seeing people that are seeking the same for authorization. When we first started Aserto people weren't even aware that externalized authorization was an option for them. They wanted to get out of the business of writing authorization logic in the application code, but they didn’t know there was a better way to build access controls. And they certainly weren’t aware of the fact that there were tools to help them extract that logic from code and build secure access controls.

When we externalize authorization the access control logic is decoupled from code and expressed as a policy that a security engineer can audit, edit, and own. Most importantly, they can reason about the authorization surface area of the entire application.

Sameer Sait:

I’m curious about timing. When you think about scaling and timing of the market, what made you realize it was the right time to build a fine-grained authorization service?

Omri Gazitt:

I knew I wanted to do another startup, and I knew that authorization was an interesting, unsolved problem that we could spend years trying to solve. I knew there was a need and a vacuum in terms of solutions.

It was pretty clear that there wasn’t a market yet. There were one or two other companies working on the problem when we founded Aserto. A year later, we had 12 other companies. So it’s clear that more people have become aware of this design pattern. But we're still in an early market phase.

Overall, you don't want to be too late, because when you're too late the winner's already been chosen. But if you're too early, you could run out before the market develops. So you have to be lucky, there's no formula for it. We're still in a very early market where innovators and early adopters understand the problem. But the early majority doesn’t and the late majority won't know about it for a few more years.

The world really knows OAuth2, and it tries to layer everything into it. But OAuth is about login time. We can stretch it to do certain things, like coarse grained authorization. If the system only has users and admins, where admins can do everything and users can do a prescribed set of things, then login time is a fine time to find out whether the user is a regular user or an admin. But if we want to do any kind of fine-grained authorization, using real time data, we really need a different protocol pattern. (More about OAuth Scopes vs Permissions here).

That's why a few of us in the authorization space got together at IIW 2023 to try to do for authorization what OpenID Connect did for authentication. We need to have that “OIDC moment” to create a rising tide for all to enjoy. We need standards and protocols to create an interoperable authorization fabric to propel the industry forward.

We started talking about what a request response protocol would look like, the architectural patterns, the PAP, PDP and PEP that first emerged in the XACML papers. We banded together and chartered an OpenID Foundation working group dedicated to authorization standards, and it was accepted. It is the AuthZEN OpenID Foundation working group. This is a very new group, founded in November, so we're in the very early innings of this initiative. But if we end up with an interoperable protocol, we can get out of this quagmire that we're in where developers lump authorization and authentication together as “auth”.

David Lee:

Now correct me if I’m wrong, but there are two sides to authorization. There's the policy that determines who can access what and there's enforcing that logic. We want the rules to change dynamically to allow for just-in-time access, and we need to enforce them in real-time.

Omri Gazitt:

That's a huge aspect of it, but it also goes back to the principle of least privilege. There is no zero trust without enforcing the principle of least privilege. Following this principle, users should only have access to what they need to perform their function, no more and no less. How do you do that? With finer grained mechanisms, such as attributes and relationships.

Interestingly, from our conversations we found that relationships are much more intuitive than attributes. You can explain to anyone that's ever used Google Docs how relationships between users and files or folders determine the access they will have. People intuitively understand concepts like parent folders, which automatically inherit the permissions to children folders or files that are contained within those folders. They also understand that we can set specific permissions on particular documents.

It's a very intuitive model, but there are still situations in which you need to use attributes, or attributes provide a more elegant solution. Some examples include authorizing based on environmental information, such as the network the user is connected to or location, as well as expressions, such as a user’s invoice approval limits.

Fine-grained authorization really is this combination of attributes and relationships. That's why we built Topaz, our open-source authorizer, to support both. Topaz combines the best of the Open Policy Agent’s attribute-based model and the Zanzibar relationship model to allow developers to express both of them. We might want to combine relationships with attributes, like time of day, so users can only access protected resources if they have a relationship to those resources and they are attempting to access them during working hours, for example. There wasn’t a project or product that allowed developers to combine attributes with relationships, so we built one.

Conclusion

As organizations grapple with the complexities of managing access controls in an increasingly interconnected digital world, the need for a fine-grained authorization service comes to the forefront. The intersection of developer tools, security considerations, and the ongoing quest for more secure and efficient authorization mechanisms underscores the challenges and opportunities in this domain.

Aserto aims to provide developers with the tools they need to build secure software without the burden of creating access control systems from scratch. As the industry continues to struggle with evolving security needs, a vision for an interoperable authorization fabric, as discussed in the AuthZEN OpenID Foundation working group, paves the way for a more secure and standardized future.

Adopting zero-trust means embracing the principle of least privilege, which in turn means you need dynamic, real-time authorization. In this world, Topaz emerges as the clear platform choice, offering developers a versatile open-source authorizer that supports every fine-grained authorization requirement. The journey is ongoing and we invite you to participate in it. If you’re an authorization vendor, join us at the OpenID Foundation AuthZEN working group. If you’re an end-user, join the discussion on the Topaz community Slack.