[HN Gopher] Launch HN: Warrant (YC S21) - Authorization and acce...
___________________________________________________________________
Launch HN: Warrant (YC S21) - Authorization and access control as a
service
Hi HN! We're Aditya and Karan, the co-founders of Warrant
(https://warrant.dev). Warrant provides APIs and infrastructure for
authorization and access control. 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!
Author : akajla
Score : 76 points
Date : 2022-07-27 15:02 UTC (7 hours ago)
| jwineinger wrote:
| How would you approach building an authorization-aware
| search/filtering functionality? It seems like you'd either need
| to ship all of the search/filtering attributes into the authz
| system, or you'd need to materialize a view of the access graph
| back into the product's database and join on it when searching.
| kkajla wrote:
| That's definitely one of the more complicated problems. One way
| we've considered approaching it is to allow customers to attach
| metadata to resources they manage via Warrant and allow them to
| query (or search) against this metadata. This obviously has its
| trade-offs (requires duplicating/syncing of data with Warrant),
| so we're still exploring solutions.
| scarytom wrote:
| I'm curious: how does this compare to https://www.aserto.com ?
| akshayshah wrote:
| It's cool to see so many authz startups over the past few years!
| Many established companies have had some bad reliability issues
| (especially Auth0), and the Zanzibar paper gives that special
| Google sheen to new products.
|
| Authzed seems to be doing pretty well in this space, but more
| competition's better for customers. Best of luck!
| schnebbau wrote:
| Just so we're clear: if you have an outage, then I have an
| outage?
| orweis wrote:
| Like Akajla said, a local Policy Decision Point (PDP) can solve
| outages really well.
|
| 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)
| akajla wrote:
| If you're using the cloud service directly, it's possible. But
| with the edge agent, all access checks will continue to
| function even if the cloud service is hard-down.
|
| 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.
| nwellinghoff wrote:
| Stuff like this is sorely needed. Glad to see people jumping on
| the problem. It would be nice if you also included all the UI
| components for managing all these permissions and users. E.g. you
| cover the model and all the UI upkeep and I just bolt it on to my
| app. The amount of man hours we have all spent reinventing the
| wheel on this area is mind blowing.
|
| 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.
| kkajla wrote:
| Completely agree re: UI components. As a full stack engineer, I
| personally dealt with the pain of permissions on the frontend
| and want to make things much easier than they are today. We've
| already started working on this. Our first foray into the idea
| is our self-service dashboard.[0][1]
|
| 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
| bsid wrote:
| We're working on the UIs portion over at Clerk
| (https://www.clerk.dev), however, we're not going all in on
| permission-ing and just giving folks enough "ABAC" so that we
| can actually power the UIs. I hope in the future we integrate
| with more powerful tools, such as warrant, to make this all
| more seamless :)
| kkajla wrote:
| Love what you're building at Clerk! Would love to work
| together. Will reach out!
| freddgn wrote:
| Congrats on the launch! One of the founders of Permify is here.
| We love this approach and Google Zanzibar paper, as we're a
| taking pretty similar approach with Permify but as an Open-source
| product.[1]
|
| 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
| jeremynevans wrote:
| Happy customer here. Warrant has been great for us so far,
| thoroughly recommend giving them a try!
| drawqrtz wrote:
| How does Warrant compare to other Zanzibar based solutions like
| Ory Keto ?https://github.com/ory/keto
| padresmurfa wrote:
| Amazing work. Thanks for sharing! Having experienced my fair
| share of pain in this area, I'll definitely be looking into the
| possibility of integrating your solution in my upcoming
| endeavour.
|
| 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.
| akajla wrote:
| Thanks for the feedback! Hoping my responses will be quoted
| properly:
|
| > 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.
| raxits wrote:
| Congratulation on the launch
|
| 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
| kkajla wrote:
| Thanks! As a developer myself, I've loved seeing companies like
| Stripe, Plaid, Auth0, etc. build solutions to hairy technical
| problems catered to developers. In my experience, technical
| leaders (decision makers) always looked to their teams when
| evaluating core technical solutions. There's nothing better
| than letting your team work with the tools they love and get
| the job the done. We've spoken to many technical leaders across
| the industry who have echoed the same thinking.
| [deleted]
| jph wrote:
| Congratulations on launch! Access control is an excellent area to
| modularize IMHO, and your approach of edge cache and data sync is
| a smart way to improve availability.
|
| 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).
| bluelightning2k wrote:
| I would never use this as is (sorry).
|
| 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
| kkajla wrote:
| Really appreciate the balanced feedback. I don't quite agree
| that rolling your own authz is that simple (especially fine-
| grained / resource-based authz), but I understand your other
| concerns, and we'll work to address them. Also, you have some
| excellent suggestions here, and we'll incorporate them into our
| roadmap. Thanks!
| orweis wrote:
| This launch and discussion is pretty exciting!
|
| 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.
| jamesmcintyre wrote:
| Having recently worked to implement a large, well-known
| authorization provider's services into a large ecommerce app let
| me share some tips from the developers perspective:
|
| 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!
| akajla wrote:
| This is all very useful, thanks for your feedback!
|
| > 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!
| Dachande663 wrote:
| If there's not an on-prem version of this, it's just a non-
| starter. As simple as.
| akajla wrote:
| Hear you on this, as mentioned in other comments, we have the
| edge agent to address performance/reliability concerns and are
| definitely looking into providing full on-prem/self-hosted
| options.
| ohmanjjj wrote:
| As a SaaS veteran I can confidently say I would never put my
| entire company on the line for a remote API call before any
| request is served. Not just latency, but also - what the heck
| happens if you're gone/down? The entire business operation grinds
| to a halt. This is such a huge non-starter. I reviewed Sync Agent
| and I doubt it is much help in case of an actual outage.
| itake wrote:
| How do you think about hosting? Should cloud providers not
| exist b/c if the provider fails, the business grinds a halt?
|
| Should products like Gmail, Auth0, Duo, PagerDuty, or Okta not
| exist because if their infra fails, the business operations
| would grind to a halt?
| tapatio wrote:
| Private DCs.
| akajla wrote:
| Very valid concern. We built the edge
| agent(https://github.com/warrant-dev/edge-agent) specifically
| for perf and reliability concerns. It's designed to run in
| customer infra with built-in storage (currently in-mem/redis)
| and can respond to all access checks even in the event that the
| Warrant cloud service is down. Writes would currently still be
| impacted if Warrant is down so this is definitely an area we're
| continuing to improve and expand.
|
| Additionally, customers have also requested their own private
| Warrant service deployments/on-prem so that's something we may
| offer more broadly in the future.
| freeqaz wrote:
| This partially answers the previous post, but it doesn't
| answer all of the concerns he mentioned.
|
| 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?
| jzelinskie wrote:
| This is why 1 year ago we open sourced[0] SpiceDB[1] under
| Apache2 and have been leading the way for open source
| Zanzibar systems. SpiceDB has contributors and users from
| the likes of GitHub and Adobe in addition to Authzed;
| building in the open and making sure that we aren't the
| only ones supporting SpiceDB is critical to the long term
| success of our users and our business.
|
| [0]: https://twitter.com/authzed/status/1443590501484032002
|
| [1]: https://github.com/authzed/spicedb
| akajla wrote:
| We have thought about it but still evaluating. In general,
| our thought here is that in case we go out of business,
| customers should be able to continue using the software
| with access to source and some level of temp support. We'd
| codify these terms into contracts. From conversations with
| others, this seems similar to how companies like Plaid,
| Stripe and LaunchDarkly handled it, especially in the early
| days.
|
| 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.
| [deleted]
| icey wrote:
| This is an awesome idea. Hope you have a lot of success, and
| congrats on the launch!
| ianpurton wrote:
| The authz solutions I've seen so far are quite good at does a
| user have permission to do x.
|
| 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.
| colinchartier wrote:
| How does this compare with existing access control solutions like
| https://aws.amazon.com/cognito/ or auth0 rbac?
| kkajla wrote:
| As others have mentioned, solutions like Cognito and Auth0 are
| primarily focused on providing authentication (authn) and stop
| at basic RBAC when it comes to authorization (authz). Many
| companies quickly outgrow RBAC or need more powerful authz
| models (fine grained, attribute based, etc.) to serve their
| business needs.
|
| Warrant focuses on the authz piece, supporting RBAC (like
| Cognito & Auth0), but more importantly, allowing companies to
| define & enforce their own authz model.
| jwineinger wrote:
| Auth0 has an upcoming authz product based on Zanzibar as
| well. They've open sourced it: https://openfga.dev/
| TameAntelope wrote:
| I don't know if Cognito is an access control solution per se,
| since it doesn't support any kind of AuthZ (AFAICT) out of the
| box.
| ukulele wrote:
| We tried cognito (bizarrely hard to use), Auth0 (mildly hard to
| use), and Userfront (easy to use) for authentication + rbac +
| multi-tenancy. We also looked at Warrant and Oso, and my
| takeaway was that they shine for more complex use cases, which
| wasn't our particular need.
| notlukesky wrote:
| Did pricing affect your decision at all?
___________________________________________________________________
(page generated 2022-07-27 23:00 UTC)