Launch HN: Warrant (YC S21) – Authorization and access control as a service
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 ...
62 comments
[ 3.3 ms ] story [ 138 ms ] threadAdditionally, customers have also requested their own private Warrant service deployments/on-prem so that's something we may offer more broadly in the future.
Even if you have an On-Prem deployment, if Warrant goes belly up, you're still hosed. Unsupported code is a recipe for disaster. What if it has a critical security vulnerability and it can't be patched? Is it legal to keep the code deployed once the contract expires and can't be renewed?
As a former Security Engineer that worked alongside the SRE team, we would never be able to justify this dependency for a production system. We'd rather build it ourselves or live with the crappier version than deal with a black box that can take down the business.
The flip side of this is an Open Source project. We regularly built around Open Source projects instead of starting from scratch when we could.
Have y'all considered moving to a license like BSL or AGPL for what you're building?
That being said, BSL/AGPL looks interesting but I'm not that well-versed in them so it's something we're going to look into more.
Similarly it would behoove you to read on the “relicensing” issues of the last few years. Many companies start small with open source to drive adoption, then discover that business model also explicitly enables others to use the same work and compete in the same space. Much heartache ensues.
[0]: https://twitter.com/authzed/status/1443590501484032002
[1]: https://github.com/authzed/spicedb
I'll definitely be looking at this for my current project.
Should products like Gmail, Auth0, Duo, PagerDuty, or Okta not exist because if their infra fails, the business operations would grind to a halt?
if we are taking authz as a need in your org and also a single point of failure for your entire services (as you said in your comment), are you suggesting you would instead build / host your own Zanzibar like authz service, and that your in-house solution would do better in terms of availability than this external solution?
leaving aside how much you'd lose on productivity, I would guess your in-house solution will break more unless you spend a lot of time making that a highly available service (and you'd depend on other SaaS for that as well, which may also break).
An in-house AAA solution.
> and that your in-house solution would do better in terms of availability than this external solution?
It won't go broke and cease to exist nor does it traverse the wild wild west that is the Internet.
I don't understand why this is a SaaS and not just a software product you buy and run on prem. (In terms of business risk, buying this as an on prem product seems perfectly reasonable -- after this startup is bought by someone like Microsoft that can actually guarantee the features will stay around.)
This kind of business sort of makes sense for customers you know having a single sign on sort of like use Google to login but I agree there's big risks for companies.
I probably don't understand a whole lot about it or about how you mitigate those risks or about what people really value there.
If it were a a product you would only merely be at the mercy of the product's source code being securely written. But as a service, you are constantly at the mercy of the entire SaaS organization's security culture. Now you have to worry about every single employee with any access at the SaaS organization getting phished. About every sysadmin at the SaaS organization accidentally screwing up a config that opens up a door into their network. About how hardcore every support person at the SaaS organization is about resisting social engineering. Yeesh, it's exhausting to think about.
You've exploded exponentially the number of things that could go wrong resulting in a security hole. All for what? Nothing, because there's nothing about this product that inherently benefits from a service model technically. There's no large data in the cloud to crunch, nothing from other customers that could benefit a different customer somehow. It ain't napster, it's just authorization. It's a damn simple solved problem and you're making it harder just so you get subscription instead of one time revenue.
If promising your customers your service is secure and/or reliable is in no way a part of your value proposition, this is an ok option, but if it is, you're crazy to put yourself in such a vulnerable position like this
Warrant focuses on the authz piece, supporting RBAC (like Cognito & Auth0), but more importantly, allowing companies to define & enforce their own authz model.
Authzed seems to be doing pretty well in this space, but more competition's better for customers. Best of luck!
And as others have mentioned, we're also planning to offer on-prem/private cloud deployments in which case the entire stack would live on customer infra.
An open-source event-driven engine like OPA+OPAL which can keep the PDP up to date is an easy way to approach this in scale (that's what we use as part of Permit.io)
To echo the other commenter, I would strongly suggest offering a self hosted option. E.g. same IAC and your cloud but I can host a copy on my cloud.
Re: self-hosting, we're definitely looking into it and plan to have a solution for it soon. Thanks for the feedback!
[0] https://warrant.dev/features/self-service-dashboard
[1] https://docs.warrant.dev/quickstart/self-service-dashboard
This area is a rapidly-increasing market need. Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (RelBAC) are all growing in technical complexity and business importance, because users are intermixing more physical devices (e.g. laptop, phone), in more environmental contexts (e.g. remote, cross-border), and with more sophisticated needs for controls (e.g. co-action, delegation).
Rolling your own is about the same level of effort, easier to mock/modify/customize as needed.
And if I wasn't rolling my own, I'd look to a library (many in NPM) or I'd look to a Kubernetes sidecar where that makes sense (Dapr or a service mesh).
Going with an API adds concerns about compliance, GDPR, inheriting your entire attack surface, inheriting your downtime risk, configuration foot-guns, and cost.
But I don't like leaving negativity - so here's some suggestions which might tip the value:
- Having really high quality RBAC front-end UI that I can just let you deal with it
- Same for inviting people to join accounts
- Testing utilities, so it becomes really easy to run the same tests with different permissions
- Similar to the above but a browser extension where a superuser can switch to emulate any other user (or admins can switch to any user in their org if policy allows)
- Audit logging and customer facing UI for viewing audit logs
I have to say I really connect with your feedback, I had exactly the same thoughts when building Permit.io: the K8S sidecar (called PDP) and frontend management experiences on top (RBAC, audit logs, invite s, ...) Are really at the core of it.
As some mentioned there are legacy tools like AWS Cognito, which mostly focuses on authentication and simpler authorization use cases. But it's evident for us, that in order to solve these problems you have mentioned[2] we need a product which can cover more complex use cases and easier to start with.
[1] https://github.com/Permify/permify
[2]https://www.permify.co/post/why-decouple-authorizations
I share other folks concern regarding a remote api call for authentication, but I think your Edge Agent solution would address most of these concerns. I’d thus hope to be able to terraform-apply your edge agent into my infrastructure.
As for UI, I imagine that I could use your supplied solutions with minor styling for admin-and-powr-user-facing use cases, while having to customize for end-user facing solutions.
I’d love to see that you also provided native mobile app samples for that, if you don’t already.
Also, at first glance,I don’t see that you take care of my third-party integrated login headaches. If not, then I’d just love to be rid of that thorn in my dev-team’s side in one fell sweep. Just sayin’, and probably revealing my ignorance at the same time ;)
My worries are towards vendor-lockin and inheriting uour attack surface, although I imagine that you will actually handle the security aspects better as part of your core business model than I would. Regarding vendor-lockin, I imagine that you could solve this with legal licensing. As a European, I’d also like to be 100% sure that all of your infrastructure was running in the EU.
Just sharing in case my opinion is of value to you, as I appreciate the solution you are attempting to bring to the world.
> I share other folks concern regarding a remote api call for authentication, but I think your Edge Agent solution would address most of these concerns. I’d thus hope to be able to terraform-apply your edge agent into my infrastructure.
Yes, that's the idea! The agent is a relatively straightforward go service with an image that can be deployed directly to k8s/cloud.
> As for UI, I imagine that I could use your supplied solutions with minor styling for admin-and-powr-user-facing use cases, while having to customize for end-user facing solutions.
Yes, the self-service admin dashboard is designed to be integrated into end user apps so that permissions management can be "delegated" to end users/admins. As mentioned in another comment, we're also looking into building UI components for common permissions scenarios (i.e. grant/revoke, view permissions etc) that can be directly bolted onto apps.
> I’d love to see that you also provided native mobile app samples for that, if you don’t already.
Great point! We've thought about building mobile clients/SDKs as well. I do think mobile has some specific requirements vs. web (connectivity, changing geo, device limitations etc) that we need to think more about in order to solve correctly.
> Also, at first glance,I don’t see that you take care of my third-party integrated login headaches. If not, then I’d just love to be rid of that thorn in my dev-team’s side in one fell sweep. Just sayin’, and probably revealing my ignorance at the same time ;)
Our approach thus far has been to stay squarely in the realm of authz and access control. Basically, Warrant works with any authn provider/IDP but we don't currently auto-sync users or handle 3rd party connections. But you're not the first to mention this so it's likely something we'll look into :)
> My worries are towards vendor-lockin and inheriting uour attack surface, although I imagine that you will actually handle the security aspects better as part of your core business model than I would. Regarding vendor-lockin, I imagine that you could solve this with legal licensing. As a European, I’d also like to be 100% sure that all of your infrastructure was running in the EU.
Very fair concerns! We're cognizant of the fact that we're building core infrastructure and so vendor lock-in and security are key questions. And yes, we'd offer customers a way to move-off in case they'd want to/need to (provide data dumps + a way to run the service for a transition period etc). We don't currently have infra in EU but again, that's something we can easily spin up as needed. In fact, we'd likely offer choice of DC/AZ directly in the product similar to how AWS and others do it.
Check similar product for more complex use case (like Menu/Tree level authorization, Web/Non-web based/Terminal/Daemon based app, LDAP/SSO/Hardware token based authentication etc.) https://arxsuite.com/
PS: I was part of Arx product suite for 5 yrs (before rebranding) :)
1. Demo is targeted towards developer & target market is B2B/Enterprise 2. Usually developer does not have purchasing power/influence + We can build it too attitude.
Happy to help
Raxit Sheth
1.) It's likely your surface area and integration-points are better designed for DX but the provider I've worked with had a large surface area, many integration patterns to choose from (likely to accommodate the plethora of customer needs over time) and because of this their documentation was often inadequate or misleading. Then you rely on support and I'll just say- please put priority on quality, experienced dev-support especially during early integration for paying customers. Also example project repos go a LONG way. I'm sure this is all stuff you're on top of but that early integration phase (especially for larger orgs) is sometimes a high-visibility, high-risk phase for the internal teams where setting them up for success and exiting that phase with a good impression would likely pay-off for the resources you invest on your side (especially if those devs, PMS, EMs, etc. then evangelize your service later at other orgs- you can imagine the inverse scenario, lol).
2.) A lot of the time, especially in larger orgs, your biggest skeptics will be deeply experienced in rolling their own auth even at decent scale. Having a healthy, substantive youtube (talks) or blog presence where you deep dive on best practices would go a long way here to alleviate their uncertainty.
3.) Supporting staging/local dev environments with as little additional dev work would be awesome. You may already accomplish this, didn't go deep into the docs.
4.) Plug-n-play logging to popular services like Datadog. Again, if orgs are coming from internal solutions to yours they'll already expect and have comprehensive logs around various auth events so making this easy would be a win.
Hope this helps! Warrant looks awesome and I'll definitely keep an eye on it for future projects!
> 3.) Supporting staging/local dev environments with as little additional dev work would be awesome. You may already accomplish this, didn't go deep into the docs.
We currently have test/prod environments for each account and will be adding staging/local envs as well (great for local/integration testing etc).
Would love to have you check us out for future projects!
But not so good at the database side of things. I.e. give me the data this user is allowed to see. Which is harder in my opinion.
I've been using postgres row level security to handle this.
More fullstack than Aserto, but less than Permit.
More pure API play, but less than Aserto.
Compared to both Permit and Aserto, Warrant seems to lack open-source standards (e.g. Open Policy)
Here's the thing, teams do this for a reason. Each one of these checks takes all of 2 minutes to add. And the next one takes 2 mins to add, and so forth. Until it's a total mess. But, as someone who been through this cycle multiple times, that's exactly what I would do again in the future. Because, on day zero, if my options are "the 2 minute solution" or "spend hours/days/weeks? evaluating a vendor for a problem I won't have for years"... well, the choice seems pretty clear there.
> As a product grows in usage and complexity, this is no longer enough. But the thing is... while it's not enough... I can add to it. Far more easily than I can to refactor everything to support a vendor provided system. And I know it'll be a big ball of mud, but at just about every decision point along the way I'm better off not switching. And every time I add something to my system, it's that much harder to adopt yours.
It feels like there's a circular dependency here. The easiest time to adopt your product (day zero) is also when I'm least likely to get value out of it. Solve that for me, and I'm very interested in your product.
This is a valid point. Although the goal should be creating a solution that is easier to start with which can be future proof.
That's both the problem and the solution. In the perfect world you'll have a solution that you can start in 2 minutes. Plus don't have to opt-in for the technical debt you will encounter in the further future.[1]
[1] https://www.permify.co/post/why-decouple-authorizations
Product looks good and polished ! Do you have any plans to add authentication as well? It would be great to have registration/authentication and access control in a single service.
Next time you want to locate a Launch HN post, scroll to the footer of HN then click on “Lists” which should take you to https://news.ycombinator.com/lists.
While on that page, click on “launches” which should take you to https://news.ycombinator.com/launches.