warrant VS postgrest

Warrant — Hosted enterprise-grade authorization and access control service for your apps. The free tier includes 1 million monthly API requests and 1,000 authz rules.

The specific challenge with authz in the app layer is that different apps can have different access models with varying complexity, especially the more granular you get (e.g. implementing fine grained access to specific objects/resources - like Google Docs).

Personally, I think a rebac (relationship/graph based) approach works best for apps because permissions in applications are mostly relational and/or hierarchical (levels of groups). There are authz systems out there such as Warrant https://warrant.dev/ (I'm a founder) in which you can define a custom access model as a schema and enforce it in your app.

Let's use warrant.dev as an example. The system provides a set of REST APIs for you to define object types and access policies (called warrants). The general process is first to create object types using HTTP POST:

https://warrant.dev/ (Provider) Relatively new authZ provider, they have a dashboard where you can manage your rules in a central location and then use them from multiple languages via their SDKs, even on the client to perform UI checks. Rules can also be managed programmatically via SDK.

I would describe this debate more as Policy-as-Data (Zanzibar) vs Policy-as-Code (OPA et al).

In Zanzibar, all of the information required to make an authorization decision (namespaces, relationship tuples, etc.) is stored in Zanzibar, and the decision engine resolves access checks based on this data. This data can be scaled horizontally (and consistently) as needed for an application’s needs. This makes Zanzibar a centralized, unified solution for all of an application’s authorization needs. I’ve found this approach more purpose built / well suited for application authorization.

With OPA and other policy engines, the data required for performing access checks lives somewhere else (maybe the application’s database) and must be separately queried and included as part of the authorization check because OPA et al. are stateless decision engines. This makes it such that you need to piece together data from different sources in order to get your final decision, which IMO is something most developers don’t want to deal with.

On the flip side, Zanzibar’s “namespaces” are a very simple policy layer not well suited to querying against data outside of Zanzibar’s scope (e.g. geolocation, time, etc). For scenarios like this, a full fledged policy-as-code solution is great. However, it should be noted that some open source Zanzibar implementations like Warrant[1] and SpiceDB[2] (mentioned in the article) also offer a policy-as-code layer on top of Zanzibar’s graph-based/ReBAC approach to tackle these scenarios.

Disclaimer, I’m one of the founders of Warrant.

[1] https://github.com/warrant-dev/warrant

[2] https://github.com/authzed/spicedb

Hey HN, I recently shared my thoughts on why Google Zanzibar is a great solution for implementing authorization[1] and why we decided to build Warrant’s core authz service using key concepts from the Zanzibar paper. As I mentioned in the post, we recently open sourced the authz service powering our managed cloud service, Warrant Cloud[2], so I thought I’d share it with everyone here. Cheers!

[1] https://news.ycombinator.com/item?id=36470943

[2] https://warrant.dev/

More than two years after choosing to build Warrant atop Zanzibar’s core principles, we’re extremely happy with our decision. Doing so gave us a solid technical foundation on which to tackle the various complex authorization challenges companies face today. As we continue to encounter new scenarios and use cases, we’ll keep iterating on Warrant to ensure it’s the most capable authorization service. To share what we learn and what we build with the developer community, we recently open-sourced the core authorization engine that powers our fully managed authorization platform, Warrant Cloud. If you’re interested in authorization (or Zanzibar), check it out and give it a star!

hey hn, supabase ceo her

we just announced GA, after ~4 years of beta. for those who don't know: supabase is a postgres hosting company. we also host other open source "backend" tools that make it easy to get started with postgres (tools like PostgREST for auto-generate APIs [0])

we owe a lot to the HN community. you launched us 4 years ago [1], when we were just a few developers. since then HN has been a staple in our journey, one of the best sources of product feedback [2]

the GA badge is mostly to signify organizational readiness. we're at a stage where we can take any profile of customer. we have a support team that works 24/7, and a success team that will help customers improve their postgres usage. we released our Index Advisor [3] yesterday, and we'll be releasing a few more products this week that helps customer with performance and security.

on a personal note: i read HN most days, and love going through the ShowHN's to see what devs are building. thanks for being an awesome community and my favorite place to lurk on the internet. i'll stick around to answer any questions

[0] PostgREST: https://postgrest.org

[1] Launch: https://news.ycombinator.com/item?id=23319901

[2] HN journey: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

[3] Index Advisor: https://news.ycombinator.com/item?id=40028111

If you use PostgreSQL and are proficient with using its row-level security feature, you can choose from several tools/services built above RLS, including Supabase, PostgREST, and PostGraphile. They all provide a way to expose database CRUD as a web API, assuming you've configured the RLS rules to properly secure the access.

wget 'https://github.com/PostgREST/postgrest/releases/download/v11.2.0/postgrest-v11.2.0-linux-static-x64.tar.xz'

SupaBase is entirely based upon PostgREST. In fact, PostgREST is arguably 49% of their value proposition according to their own website. The other 49% is PostgreSQL. PostgreSQL of course is a super mature database, and some would argue the best RDBMS on the planet, so let's ignore that part for a moment, and consider it a mature thing and move on to PostgREST.

You don't need this PHP snippet:

To get the same functionality without the extra step, simply use PostgREST [1]

[1] https://postgrest.org/

PostgREST is a standalone web server that turns your PostgreSQL database into a RESTful API using the database's structural constraints and permissions to define the API's endpoints and operations. In this tutorial, you will create a simple note-taking app by leveraging PostgREST to construct a RESTful API for the app and using htmx to deliver HTML content.

You might find some info in the docs of PostgREST [1] or in the previous discussions on HN about it [2].

For the versioning, I just have a git repo where I keep every role, schema, table, view, function, trigger, etc. definitions. Every time I change something in the database I first change it in the git repo too to have an history.

[1] https://postgrest.org

[2] https://hn.algolia.com/?q=postgrest

Don't know if you would call this a "program" but PostgREST is written is Haskell too.

https://github.com/PostgREST/postgrest