Well noted. Thanks again

my pleasure

Hi guys, I'm kind of new to advance permission systems like Zanzibar. What I'm going to ask is maybe not related to Zanzibar but you are the experts in this field so you are the ones I should ask this question. So, there is a one problem I'm have in my mind all the time which is how to restrict certain fields to a specific subject. Let me explain this more, Let's say there are two subjects called user and product. Product has fields like sku, price, category, weight, etc. My problem is how to restrict these fields based on the user? (it can also based on user role for performance reasons) Like one user can read only price and category while another can price and weight. What I thought first is write permissions in the definition for all these fields. Is this not good in performance wise nor the industrial standards? Like everywhere I'm watching authorization handling no one is restrict low level fields in a system entity. Only the entity itself. I was also watching your yt videos, but I couldn't get any clue with this.

@lotus are those fields predefined or dynamic?

Predefined

you'd typically define them as permissions and grant them to users

performance wise, this is fine

Have you used this kind of permissions when you're working on production/professional projects?

It’s a fairly standard approach

Hello, everyone 🙋‍♀️

welcome!

Thanks Joey, wishing you best of luck with the project ❤️

Hello again, is there a way to fetch all the permission a specific user has for a specific resource? Lets say there are relations like,

product:product_1#price_viewer@user:user_1

product:product_1#category_viewer@user:user_1

So how to get all the permissions user_1 has on product_1 at once?

@lotus you'd issue a Check for each, in parallel

Hi Apologies if this question has been asked already do you have any performance bench marks for authzed both as sass or self hosted. Any details would be great. We have an existing IDP which is doing roles as well but not suited for longer term RBAC's. So would good know what the performance implications would be of plugging in authzed. Ideally self hosted in AWS.

hi @gpa: performance very much depends on your schema and datastore, but checks are typically around 20-30ms in most standard schemas when calling SpiceDB from within the same cloud provider. If you intend to self host on AWS, then you'll need to decide what datastore to use (Postgres, MySQL, CockroachDB, etc) and that will inform your performance. If you want the "best of both worlds", Authzed does provide a Dedicated product where we will deploy everything in a cloud provider of your choice as well.

@Joey Thanks for the info that's much appreciated. I have use case whereby although we need RoleBaseAccess we need the ability for override some permission within the role for some users which can only be done someone with a higher level role , dynamically. Is this possible. What would we need to do support this if this is possible?

Does anybody know of a Node.js package that offers Zanzibar-esque ReBAC behaviour? E.g. a library to help you implement "lightweight" (e.g. no zookies) ReBAC in a Node.js service where you don't want/need the overhead of a separately hosted authorization service?

would this still be against an external datastore?

Yes

well, there are few options I can think of offhand: you could run SpiceDB as part of the same pod as your NodeJS service, with dispatching and caching turned off, which wouldn't make it in-process, but be as close without actually being part of NodeJS

you could in theory also WASM in SpiceDB, but I don't know if that would support calling out to an external datastore

beyond the SpiceDB options, I imagine it wouldn't be too difficult to write a very, very simple shadow of a ReBAC system, but it would likely become unmanageable in the long term

because you want to talk to an external datastore, I'd suggest option #1: it provides the ability to migrate to a non-lightweight version very easily by simply removing the container from the pod and deploying as a distinct service down the line

Thanks; I think indeed that running it in a "sidecar" is probably the most pragmatic way to do it. The use case I'm considering it for is a greenfield service, so I have some freedom there. The only thing that's on my mind is the slight added complexity for orchestrating infra for this (so far, the small project is starting off as a nimble modular monolith with one service, PostgreSQL being the only dependency). But it's pretty easy to manage I reckon and for the local dev env I could just add SpiceDB in the already existing docker compose config I'm using for PostgreSQL.

yeah

The big upside of course is that if this project (hopefully) grows in size and maturity, splitting the modular monolith up into services would be easier if FGA is already separately hosted

exactly

and if you're doing something like a dev environment, you could even run SpiceDB with in-memory datastore and with preloaded data