Comments URL: https://news.ycombinator.com/item?id=48165902

Points: 85

# Comments: 26

[1]: https://discord.com/invite/GBeT3R4k84

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

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.

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#authz... [2]: https://authzed.com/docs/spicedb/modeling/protecting-a-list-...

Then, I'd take a look at the history of SpiceDB [2] for how we developed the system over time.

Finally, if you have any questions, feel free to jump into our Discord [3] and ask: we're happy to answer!

[1]: https://zanzibar.tech/ [2]: https://spicedb.io [3]: https://discord.gg/spicedb

Generally, the solution is to keep a timestamp of when the data changed (Zookies as you mentioned) or you can proactively reload or recompute the cache when the underlying data changes (sometimes in very smart ways), but yeah: it adds significant complications over a "simplified" approach to Zanzibar.

Disclaimer: I'm the cofounder and CTO of AuthZed and we develop the SpiceDB [2] and Materialize [3], which have quite a bit of logic around these exact problems

[1]: https://authzed.com/blog/new-enemies#the-new-enemy-problem [2]: https://spicedb.io [3]: https://authzed.com/docs/authzed/concepts/authzed-materializ...

Yep, as I mentioned above, its not an easy problem but once it is solved for you, it becomes "just" watching the events and performing the JOINs.

> especially if we could create an extension for other databases

See my video I linked above about the Postgres FDW: It does exactly this for SpiceDB and works seamlessly as-if there is a denormalized permissions table sitting in your Postgres, while still supporting the full array of complex authorization rules found in ReBAC.

However, as you mentioned, life is easier when the main database can handle everything, so we actually built a solution in that space called Materialize [2], which heavily denormalizes the authorization data and allows for joining within application databases such as Postgres. My colleague Evan actually put together a really cool video about using it with Gitea [3].

Recognizing that even with Materialize, however, the need to consume events can be a bit annoying, I've been doing some work to allow Postgres itself to do native JOINs against SpiceDB (and other operations). I demo it briefly in our recent announcements video [4] and I think it effectively solves this problem within Postgres, while still allowing for all the benefits (scale, performance, redundancy, distribution) of externalized authz.

[1]: https://authzed.com/docs/spicedb/modeling/protecting-a-list-...

[2]: https://authzed.com/products/authzed-materialize

[3]: https://www.youtube.com/live/u3i1SEd9Ll8?si=mCz5mZterxthoEwj

[4]: https://www.youtube.com/live/uz_gxz3whS0?si=g4NUZAIltYVyFzYj...

Disclaimer: I'm cofounder and CTO at AuthZed and we build SpiceDB and Materialize

Source: I co-founded Quay.io

Comments URL: https://news.ycombinator.com/item?id=42087709

Points: 6

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=41095167

Points: 2

# Comments: 0

In a previous HN post [2], we discussed how we moved the playground to use WASM for running SpiceDB, massively improving performance. Today, we're happy to open source the frontend side of the playground, so that everyone can see how it works and make improvements!

[1]: https://github.com/authzed/playground [2]: https://news.ycombinator.com/item?id=32595310

Comments URL: https://news.ycombinator.com/item?id=39895974

Points: 5

# Comments: 2

With multiple data sources reading and writing to SpiceDB [1] (our OSS implementation of Zanzibar), those questions can further be extended into "Can [subject] [action] on [resource]", which allows for supporting not just permissions, but (as you suggested) feature flags, entitlements, role-based access control and even billing-based entitlements (if the billing system's information is supplied in as relationships or dynamically via caveat context [2]).

As a concrete example, feature flags can be represented as a straightforward permission:

  definition user {}
  
  definition featureflag {
    relation enabled: user
    permission is_enabled = enabled
  }

  check featureflag:somefeature is_enabled user:{currentuserid}

  definition organization {
    relation member: user
  }
 
  definition featureflag {
    relation enabled: user
    relation org: organization
    permission is_enabled = enabled & org->member
  }

With caveats [2], these kinds of questions can even depend on dynamic data, such as the time of day, whether the user's account balance is positive, or even be random based on some distribution (to enabled, for example, partial enablement of feature flags)

[0]: https://zanzibar.tech/ [1]: https://spicedb.io [2]: https://authzed.com/docs/spicedb/concepts/caveats [3]: https://play.authzed.com/s/eML6cLz9ByAZ/schema

Disclaimer: I'm CTO and a cofounder at AuthZed, and we build SpiceDB