When I first heard about what the Veza team was doing, I frankly wasn’t sure it was possible. Coming from Okta and leading the product management team there for over 4 years through their IPO had taught me some tough lessons. In particular, building integrations, building a lot of them, and building them quickly is key to success. Both Veza and Okta are similar in that they need to be integrated into other systems to be valuable to customers. But in many ways, the problem of authorization that Veza is solving is more complex than the authentication problem that Okta solves.
A good way to compare these two technical challenges is to look at the state of industry standards. For authentication and federation, the SAML 2.0 standard has been around since 2005 and, more importantly, is widely adopted. More modern standards like OpenID Connect (OIDC) are gaining traction. In comparison, authorization standards are still in their adolescence. OAuth 2.0 has been around for a decade, and it’s OK as far as it goes. There is some discussion around OAuth 2.1 or 3.0, but I’m not holding my breath. The key point is that these are really “frameworks”, not true standards. That’s because they leave a LOT of details open-ended and unspecified. This isn’t really surprising, since authorization is so much more complex than authentication. In authentication, you essentially need to make a yes or no decision. In authorization, you need to address the complexity of all the different actions and different objects that could be involved. Most importantly, these actions and objects aren’t standard and vary widely between apps and systems. Open-source projects like those for the Open Policy Agent (OPA) and Rego are good but are only useful if you’re building a new app. What about everything you’ve already built and all the apps, platforms, and systems you already use? In my opinion, the lack of progress and detail around standards for authorization comes down to the fact that it’s just too complex to get a broad agreement from everyone involved.
The implication of a lack of authorization standards is that, practically, it’s harder to do each integration. You really need to dig into the details of each app or service to understand what’s there and what’s possible. You need to understand how that system treats users, roles, groups, objects, nested objects, hierarchies, local users, ACLs (or their equivalent), service accounts, etc. How are permissions granted to each identity, to each object, and/or to each action? If someone or something does have permissions, how did they get it? You need to not only know if an action is allowed on a particular object, but you need the underlying path to get that permission in order to understand how to fix it. Sometimes, deciding the right way to fix broken permissions can be harder than seeing what the reality actually is.
The good news is that you don’t need to boil the ocean to deliver value- you focus your efforts on the most important things (“thank you, Captain Obvious!”). First, you focus on the systems that have the “crown jewels” of the organization. Customer data, employee data, and source code tend to top the list. Pick those systems that contain that data, and you’ve got a great start. Second, you don’t need to do everything- start basic and mature. Maybe you just want to get centralized visibility to who local users are on a system, or see all the accounts accessing AWS that aren’t listed in your corporate identity system. Maybe you want to know which offshore contractors have access to your source code? Simple, but critical questions.
That leads us to Veza’s integration strategy, which is a two-pronged approach. The first is building native integrations in the product. These are for target systems that are larger, more complex, and with the highest demand across our customer base. Examples include AWS, Azure, Google Cloud, Snowflake, and SharePoint Online. The second prong is building integrations via the Open Authorization API (OAA). These integrations are for less commonly needed systems, simpler ones, or even custom apps. Examples include Github, Bitbucket, and JIRA Cloud. Over time, these integrations may become native integrations, or they could be a choice of type. Basically, OAA integrations are to address the Long-Tail problem.
So, how do OAA integrations work? Basically, there is a small chunk of code that runs outside of the Veza SaaS infrastructure: the connector. The connector has 3 jobs: it needs to pull authorization data from the target system (i.e., app, data storage system, or service), transform that data into a format Veza can understand, and call the Veza API to import the data into Veza. After that, you get all the goodness of Veza for the new target integration- goodness that helps you understand and manage who can and should take what action on what data- now for any system!
There are a number of advantages to integrating via OAA. First, it’s faster. It doesn’t need to be Veza engineering that builds the integration (specifically, code for the connector)- it can be, or it could be you (as a customer) or a third party. The answer doesn’t need to be the dreaded “it’s on the roadmap” response from a product manager- you have the option to self-service. Second, it’s free (or at least “included”). We recognize that there is a bit more effort for customers to implement an OAA integration, so support for the API is included with the base product every one of our customers buys. Third, it’s easy. We have an OAA Community site hosted on Github (Veza on GitHub). Here, you’ll find an SDK, technical docs for developers, sample code, and examples of connectors you can take and use for free.
Both Veza employees and our customers have posted connectors in the Community for others to take, adapt, and use. Our customers have built OAA integration to 3rd party SaaS apps, on-prem apps (like Oracle Simphony), and IaC Saltstack files.
One of the most powerful things you can do with the OAA is integrate your custom apps into Veza. Your developers are the ones that know your app best, and how the authorization scheme works. No one is going to have an out-of-the-box integration for your app without a large consulting engagement, so some building will always be needed. If you’re using OPA to build your custom apps, great! OAA easily integrates with OPA. Most custom apps leverage standard cloud platforms and data systems under the covers. Once you can get the users, groups, and roles into Veza, you get the benefit of the other integrations that are already there (e.g., to AWS, GCP, and Azure). Wouldn’t it be useful to really know what customer data your customer support representatives are able to see, edit, and delete in the course of resolving a case within your custom app? This was exactly the scenario for Okta in their recent incident with Lapsus$, where it was reported that up to 366 of its customers were potentially impacted by an intrusion into the computer of an outsourced customer support representative*. One of our early customers integrated their custom Customer Support portal so they could use Veza to manage these permissions. I remember asking our champion how long it had taken him to build. He answered, “Two cups of coffee on Saturday morning.” Not every app will be this fast to integrate, but it is a great example of how quickly you can get started.
Fundamentally, there is a deeper reason we took the approach of providing the APIs to connect to our platform. We believe that openness is the right approach for enterprise products. We want our customers to experiment and discover for themselves the power of being able to visualize and manage authorization in any system. Because of the complexity of the problem we’re trying to solve together with our customers, there is no one-size-fits-all solution. Our customers are brilliant, and we want to build a community that taps into that brilliance. Learn more about what we believe in our Manifesto.
*TechCrunch, “Lapsus$ found a spreadsheet of accounts as they breached Okta, documents show”, March 22, 2022.
