Hi Guys, we are exploring zanzibar/spicedb for aut...
# zanzibar
y
Hi Guys, we are exploring zanzibar/spicedb for authz engine, have some doubts, posted in stackoverflow https://stackoverflow.com/questions/74311608/zanzibar-doubts-about-tuple-check-api-authzed-spicedb Not sure it's the right way to ask, but re-posting the same here as well...apologies if it's too long. We currently have a home grown authz system in production that uses opa/rego policy engine as core for decision making(close to what netflix done). We been looking at Zanzibar rebac model to replace our opa/policy based decision engine, and AuthZed got our attention. Further looking at AuthZed, we like the idea of defining a schema of "resource + subject" types and their relations (like OOP model). We like the simplicity of using a social-graph between resource & subject to answer questions. But the more we dig-in and think about real usage patterns, we get more questions and missing clarity in some aspects. I put down those thoughts below, hope it's not confusing... [Doubts/Questions] 1. [tuple-data] resource data/metadata must be continuously added into the authz-system in the form of tuple data. -- e.g. doc{org,owner} must be added as tuple to populate the relation in the decision-graph. assume, i'm a CMS system, am i expected to insert(or update) the authz-engine(tuple) for for every single doc created in my cms system for lifetime?. -- resource-owning applications are kept in hook(responsible) for continuous keep-it-current updates. -- how about old/stale relation-data(tuples) - authz-engine don't know they are stale or not...app's burnded to tidy it?. 2. [check-api] - autzh check is answered by graph walking mechanism - [resource--to-->subject] traverse path. -- there is no dynamic mixture/nature in decision making - like rego-rule-script to decide based on json payload. -- how to do dynamic decision based on json payload? Appreciate any input.
2 Views