[HN Gopher] Permission Systems for Enterprise That Scale
___________________________________________________________________
Permission Systems for Enterprise That Scale
Author : eliocs
Score : 85 points
Date : 2025-12-24 09:50 UTC (13 hours ago)
(HTM) web link (eliocapella.com)
(TXT) w3m dump (eliocapella.com)
| bencyoung wrote:
| If you're using Postgres then using the ltree module is great for
| permission systems. Available in RDS too
| casper14 wrote:
| Could you explain why this is great over alternatives?
| nh2 wrote:
| Do you have an article about that?
| calderwoodra wrote:
| Agreed, specifically for the file structure use-case, we were
| able to solve this with ltree.
| amcvitty wrote:
| About to embark on a similar project. Would love to hear any
| insights you can share!
| charcircuit wrote:
| >We added a point of failure, as the permissions table can get
| out of sync with the actual data.
|
| >The main risk with pre-computed permissions is data getting out
| of sync.
|
| It would make sense to have permissions be a first class concept
| for databases and to ensure such a desync could never happen.
| Data being only read or written from specific users is a very
| common thing for data so it would be worth having first class
| support for it.
| valiant55 wrote:
| I'm struggling to understand what the issue that the author is
| getting at. The point of a database is that it's ACID
| compliant, wrap insets/updates/deletes in a transaction and no
| such drift would occur. What am I missing?
| charcircuit wrote:
| I don't think you are missing anything. I think he is just
| pointing out that technically nothing is enforcing this
| synchronization, so if someone forgets to wrap things in a
| transaction, it could get out of sync.
| eliocs wrote:
| I just want to point out you have to take care about that,
| yes you can have a trigger or a transaction to make sure it
| happens but it isn't there out of the box
| ahsisibssbx wrote:
| Depending on your DBMS and isolation level, using a
| transaction might not fix things. That being said I don't
| think (at least for Postgres) most people are using an
| isolation level that could cause this.
|
| Much more likely I think is that you can't use the db to
| prevent invalid states here (unique constraint, etc) and
| you're dependent on other areas of the code correctly
| implementing concurrency controls. Race condition in resource
| A causes problems in your permissions table now.
|
| And just from a general engineering perspective, you should
| assume things are going to fail and assess what your path
| forward looks like when they do. Recovery script sounds like
| a good idea for a critical area.
| eliocs wrote:
| Lot of 'new' databases are basing their moat on this and sync
| engines. Eg: supabase, zero.dev, jazzdb, etc.
| jeffbee wrote:
| Why is it a useful property that everything is always "in
| sync"? I propose this is not possible anyway. These systems are
| always asynchronous, and the time of check is always before the
| time of use, and it is always possible that a revocation occurs
| between them, and this problem cannot be eliminated.
| tekkk wrote:
| Strange the article proposes itself for "Enterprise" yet has no
| mention of Google's Zanzibar and how it compares to the other
| approaches. AFAIK it doesn't use pre-computed values but just
| queries really fast (using Spanner so there's that)
| smarx007 wrote:
| And https://projects.eclipse.org/projects/technology.biscuit
| eliocs wrote:
| Can you let me know how would you for example query all
| accessible resources for a user using Google's Zanzibar?
| phrotoma wrote:
| Related: if anyone has a method of achieving this query
| against GCP resources I'd be keen to learn that as well.
| jschorr wrote:
| We actually have users that synchronize their resources
| from various sources (AWS, Kubernetes, etc) into SpiceDB,
| explicitly so they can perform these kinds of queries!
|
| One of the major benefits of a centralized authorization
| system is allowing for permissions queries across resources
| and subjects from multiple different services/sources (of
| course, with the need to synchronize the data in)
|
| Happy to expand on how some users do so, if you're curious.
| jschorr wrote:
| In SpiceDB, this is known as the LookupResources [1] API,
| which returns all resources (of a particular type) that a
| particular subject (user in this case) has a particular
| permission on.
|
| We have a guide on doing ACL-aware filtering and listing [2]
| with this API and describing other approaches for larger
| Enterprise scales
|
| Disclaimer: I'm the co-founder and CTO of AuthZed, we develop
| SpiceDB, and I wrote our most recent implementation of
| LookupResources
|
| [1]: https://buf.build/authzed/api/docs/main:authzed.api.v1#a
| uthz... [2]:
| https://authzed.com/docs/spicedb/modeling/protecting-a-
| list-...
| svaha1728 wrote:
| If you are interested in Zanzibar and Relationship-Based Access
| Control (ReBAC) it's worth taking a look at OpenFGA
| https://openfga.dev/
| mirzap wrote:
| There are quite a few OSS Zanzibar-inspired authorization
| services/servers: - SpiceDB
| (https://github.com/authzed/spicedb) - Permify
| (https://github.com/Permify/permify) - Warrant
| (https://github.com/warrant-dev/warrant) - Ory Keto
| (https://github.com/ory/keto)
| jschorr wrote:
| Google's Zanzibar actually does _both_ : for the vast majority
| of queries, it uses significant levels of caching and a
| permitted amount of staleness [1], allowing Spanner to return a
| (somewhat stale) copy of the relationship data from local
| nodes, rather than having to wait or coordinate with the other
| nodes.
|
| However, some deeply recursive or wide relations can still be
| slow, so Zanzibar also has a pre-computation cache called
| Leopard that is used for a very specific subset of these
| relations [2]. For SpiceDB, we called our version of this cache
| Materialize and it is designed expressly for handling
| "Enterprise" levels of scale in a similar fashion, as sometimes
| it is simply too slow to walk these deep graphs in real-time.
|
| [1]: https://zanzibar.tech/24uQOiQnVi:1T:4S [2]:
| https://zanzibar.tech/21tieegnDR:0.H1AowI3SG:2O
| Xmd5a wrote:
| https://docs.feldera.com/use_cases/fine_grained_authorizatio...
|
| Fine-grained authorization as an incremental computation problem
| eliocs wrote:
| How would you achieve fast list queries of accessible resources
| with this approach?
| gz09 wrote:
| feldera has a way to run ad-hoc/list queries on materialized
| views. Alternatively, you can send the result somewhere where
| you can query it.
| gneray wrote:
| Yes we've implemented this at Oso.
| ExoticPearTree wrote:
| Another approach to complex requirements without spending a lot
| of time querying databases is to use bitmaps. A set of
| permissions can be expressed through a bitmap and all you need to
| do in code is to "decode" that to what you actually let the user
| do.
|
| The downside to this approach is that it requires some planning
| and to maintain in code what mask retrieves what permission(s).
| the_arun wrote:
| Isn't Open Policy Agent (OPA) and Zanzibar not good enough to be
| in the article or author talking about specific permission
| controls?
| bitweis wrote:
| Permit.io
|
| Scales both on the tech, and on the human side - e.g. your
| product manager can add roles (with CI approval) without
| requiring engineering involvement.
|
| (I'm biased but still true)
| afiori wrote:
| I only did a quick read of permit.io offering but iirc they
| don't focus on hierarchical data. If having access to a
| resource cannot grant access to unbounded number of other
| independent resources (eg sharing a folder) then almost all
| issues of the article disappear
___________________________________________________________________
(page generated 2025-12-24 23:01 UTC)