Teams typically implement their earliest version of an access control system with a home-grown solution or an open source library. Many implement role-based access control, often with roles, attributes, and authorization logic hard coded and/or tightly coupled with their business logic.
As a product grows in usage and complexity, this is no longer enough. Teams find themselves constantly modifying their access control system as their product evolves, or building whole new systems to meet their ever-changing needs. Some teams move towards fine-grained, resource-based access control. Some require attribute based access control. Adjacent problems like multi-tenancy/data isolation, pricing tiers/entitlements, feature flagging, and audit logging come into the picture as well. The problems and the solutions are endless, and typically only large companies have the resources to build and maintain a system that does it all.
We’re software engineers who worked for years on access control systems at companies like Lyft, Yahoo, AppLovin, and Medallia. We often found ourselves spending time maintaining and iterating on these in-house systems to keep up with new product, infra, and security/compliance requirements.
Later, while building our own SaaS product, we had to implement access control yet again, and we realized three things: (1) Implementing access control is necessary but tangential to building core product features, so it should be standardized somehow. (2) Access control systems are difficult to maintain as a product evolves, and changing an authorization model or access rules often requires developer involvement. (3) While role based access control (RBAC) still has its place, modern applications require more powerful and customizable authorization models. For example, a data analytics product might want to express that “a specific user X can edit report Y” rather than “all admins can edit reports.” In the end, we built a service to manage and enforce access rules for our SaaS product. We quickly realized access control was a much more compelling problem to solve for engineering teams, and that service became the first version of Warrant.
Warrant is a fully managed access control service accessible via API/SDKs. As fans of Google’s approach to authorization and access control, we based Warrant on Google Zanzibar (https://research.google/pubs/pub48190/). Users can define custom authorization models for their applications via flexible “object types” or use built-in models to quickly implement common authz scenarios like RBAC and Multitenancy. Our dashboard makes it easy for anyone from developers to product managers to manage an application’s authorization model and access rules.
We’re a centralized service, which raises two obvious issues: (1) the latency/reliability concerns of adding a network request to nearly all requests, and (2) the tedium/bloat of keeping data and access rules in sync via API/SDK calls. We’ve built solutions for both of these. Teams can start with our fully managed cloud offering—the simplest approach—and then move to these more specialized solutions as their needs evolve.
Teams with strict latency/availability requirements can run our Edge Agent (https://docs.warrant.dev/quickstart/edge-agent) on their own infrastructure to minimize the latency of access checks and improve reliability in the event that Warrant faces an outage. The Edge Agent services access checks from a local cache and connects to Warrant to receive updates in real-time.
Teams looking to avoid the overhead of integrating via API/SDKs can run our Sync Agent (https://docs.warrant.dev/concepts/sync) alongside their database to stream changes to their data directly to Warrant. With object types configured for syncing, Warrant Sync automatically keeps access rules up-to-date.
As developers, we’re focused on providing stellar developer experience, so we also created an easy way to perform client-side access checks: https://docs.warrant.dev/quickstart/creating-sessions. Our client-side SDKs for React, Vuejs, and Nextjs provide components that make it easy to build dynamic UIs based on a user’s access rules.
We currently handle authorization in production for startups and indie developers alike. If you’d like to try us out, sign-up for an account at https://app.warrant.dev/signup (free, no credit card required) to get an API key and refer to our docs at https://docs.warrant.dev/ to get started.
We appreciate your time and feedback HN! Let us know what you think in the comments!
by Andrey
Azimov