We sat down with the team at Jasper to talk about how they're using Oso Cloud to meet the demands of enterprise customers as they take their AI-driven Marketing platform upstream.
What prompted Jasper to reevaluate their authorization code?
We were moving upmarket and started targeting enterprise customers. These customers needed more comprehensive and more granular authorization controls than our original customers, so we needed to make our authorization code more flexible.
For example, we had only needed two roles before this: an admin role that could manage everything and a member role that didn’t have any of the management permissions. Enterprise customers wanted to have in-between roles that could do things like manage knowledgebases or the tone of voice for a company, but not have access to things like billing information. Our model didn’t support that.
What were the main considerations for the project?
The speed of the implementation and overall developer velocity were the main concerns. We were getting authorization requests from enterprise customers that our existing code didn’t support, so we needed to address those quickly. We had also just brought on a new CEO who wanted us to address the gaps in our authorization code as quickly as possible. At the same time, we didn’t want the new system to take developer time away from our core functionality.
Why did you decide to use an external solution instead of building it in house or using on-premises open source?
When we drew out architecture diagrams, we modeled the authorization service as an encapsulated “black box.” We quickly realized that if we built or implemented that service ourselves, we’d have to understand and support what was going on in the box, which was contrary to our developer velocity goals. Since authorization isn’t our core use case, it made sense to offload that responsibility to a vendor.
You initially evaluated Google Zanzibar implementations. What made that model compelling to Jasper?
We heard a lot about Google Zanzibar when we were doing our research. Knowing that it powered Google’s applications, given their requirements for scale, performance, and availability, gave us confidence that the model would meet our needs.
One of our core features is a file- and folder-based document management system similar to Google Drive. This fits very well into a Zanzibar-style relationship-based access control (ReBAC) authorization model, so that was also a good fit for us.
What led you to consider and eventually adopt Oso instead of a pure Zanzibar implementation?
We still have a lot of use cases that don’t fit a relational model. We have a more traditional role-based access control (RBAC) model for users and organizations. Many of our permissions are assigned to these roles. We also have some planned features that use attribute-based access control (ABAC). For instance, we want to be able to give the owner of a resource elevated permissions on that resource, such as the ability to delete it or add it to views.
Oso lets us start off with RBAC and then build in ABAC and ReBAC capabilities as we need them. It doesn’t force us into any of those models. Oso lets us use the authorization pattern that best fits the feature we’re building, which lets us meet our goals for the speed of implementation and keeps our developer velocity high.
We also found as we were evaluating vendors that Oso’s support and responsiveness stood out from the others. Google doesn’t provide Zanzibar directly, so we evaluated a few vendors that provide hosted Zanzibar implementations. Because authorization is so important to our application, Oso’s exceptional support gave us confidence to work with them on our implementation.
Now that you’ve started implementation, what has the experience been like?
Right off the bat, Oso let us move quickly and meet the aggressive timelines we set for this project. We were able to meet directly with your team when we had questions and their support saved us a lot of time. Oso has been able to handle all of our initial RBAC requirements and we know that we’ll have your support as we start building the ABAC and ReBAC capabilities into the model.
You built a wrapper around the Oso library. We hear this a lot. Can you tell us a bit about why you did that and what benefits the wrapper provides for other people who may be considering something similar?
The wrapper’s mainly a proxy into Oso. The primary use is to emit logs to record what user is changing permissions or changing their role. Our security team has a requirement that we send that information to Datadog so that they can know who’s changing what. The wrapper gave us an easy way to customize the logs to meet their requirements.
Your model has an interesting feature: there’s a default set of permissions, and permissions are revoked from specific users based on toggles. What drove that model and how has it been to implement it in Oso?
As we’ve moved to enterprise customers, we’ve had to evolve to be flexible to the needs of each customer. Those needs vary very widely, from “I want everybody to have access to everything” to “I only want 3 people to have access to this feature.” Our general approach to the core feature set has been to make those features toggleable by role. So we can say “if this toggle is off, then everyone has access to the feature, but if it’s on, then only admins and middle managers have access.” This has made it much easier for us to tailor the features to whatever a given organization may need, or whatever their security requirements specify.
We tried to implement it a few different ways, and then we met with Sam (Oso’s CTO) and he guided us toward the best way to do it. I wouldn’t say we did it incorrectly, but there was more than one way to do it and he recommended the most scalable approach. We found good guidance in the docs that we used for our initial implementation, but because this is a bit of a unique use case, Sam gave it some thought and was able to show us how to improve it.
Is there anything you’d like to see from Oso?
We’d love to have more tools for engineers who are outside the team to diagnose unexpected behavior from the Oso authorization logic. When someone doesn’t have access to a feature they think they should, they need to come to us to figure out why. If they could query the logic using SQL rather than having to understand Polar, they could do more of that investigation independently.
Any last thoughts?
Of the vendors we work with, Oso is among the most helpful. Everyone we’ve talked to, from contract negotiation to working with the engineers has been very supportive and able to jump on board and work with us.
Having a shared channel where you announce talks and new features has been very helpful. And going back and forth with us on the policy design made the initial implementation easier and set us up for the long term. You came to us to set up time to meet and talk through the initial implementation without us having to request it. That whole onboarding experience was very nice.
Thank you!
