Those are streaming gRPC APIs

if that returned way too many values for your application to handle, the last resource is denormalizing authorization closer to your database with

LookupWatch

. That's still WIP: https://github.com/authzed/spicedb/issues/207

There is a nice blog post about ACL filtering at https://authzed.com/blog/acl-filtering-in-authzed/

hello, I'm trying to model the concept of reusable roles. The idea would be to create a RBAC layer on top of ReBAC the following way: 1. users can be assigned to groups 2. groups can be assigned to roles 3. roles have a set of permissions related to the type

thing

, but not to a specific object id 4. (to keep it simple) the

things

are related to groups the resolution would be that if a user belongs to a group assigned to the thing and at the same time belongs to a role with the requested permission then they are allowed. In my attempts to model this, I always end up with roles being assigned to a specific object id, making them non-reusable (i.e. multiple assigned need to be done to each object id, at which point groups become useless and users could be assigned directly to roles.

> roles being assigned to a specific object id can you expand on that?

how would y'all go about modeling permission to connect a resource to another resource? like if i have groups and documents and admins of groups are allowed to add documents that they own to a group. but non-admins cannot add documents, and admins cannot add documents they do not own. would it look like this?

type user {}

type group {
  relation admin: user
  relation member: user

  permission add_document = admin
}

type document {
  relation owner: user
  relation editor: user
  relation viewer: user
  relation group: group

  permission add_to_group = owner // no way to assert about the group being added to here because it is not yet related!
}

and then the operation simply requires to permission checks?

if you're operating over two distinct subjects, yes, you'd need two checks

Hi guys! I have a question about Zanzibar paper. In Zanzibar, every namespace has a specific database for storing relationship tuples, but in SpiceDB it is only one database for all namespace relationship tuples. What's the reason for this change?

the vast, vast majority of use cases do not require that level of sharding, so we simply did not do it. if/when it becomes necessary, we'll likely evaluate that as a possible optimization around data storage and retrieval, although it makes certain kinds of operations much, much harder to do efficiently (mostly reverse walks)

is there a way to constrict assignment via a relation? For example:

type user {}
type district {
    relation admin: user
}
type site {
    relation district
    relation site_admin: user // <- is it possible to limit this down to a user must be an admin of district?
}

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.

hi there, you are correct that the calling application(s) are responsible, either directly or indirectly, for keeping the relationship data up to date. if you intend to have a unique role/relationship for each document in your system, then yes, you do need to insert/delete those relationships as the referenced resources (or the roles on them, more likely) change, but if you are using an RBAC-like design for your schema, you'd have to apply these role changes anyway; you'd just apply them to SpiceDB/Authzed, instead of to your database. Likewise, if you have a relationship between say, a document and its parent organization, you do have to write/delete those as well, but that should only occur when the document is created or deleted.

in practice, unless you intend to keep the relationships in both your database and in SpiceDB/Authzed (which some users do), you'll generally only have to write them to one or the other. if you do intend to apply them to both, you can either just perform the updates to both at the same time, or use an outbox-like pattern to synchronize behind the scenes

as for dynamic decisions: that is what the caveats proposal currently being implemented will solve: https://github.com/authzed/spicedb/issues/386

@yezb feel free to ping if you have any followup questions/concerns

Hi Joey, thanks for the details, have to read thru to grasp all, especially the "caveats proposal"...in the rbac like design, you mentioned "you'd have to apply these role changes anyway" - could you elaborate pls? do u mean a user add/remove to a role in authzed?. Managing user+role relationship in authz system is what we do currently, so that part i understand - it's almost a predefined relational set. but sending metadata for each instance of resource is a lot for other apps like CMS - that's a every growing data set. And what are the recommended way to tidy up those stale relation-tuple(e.g. document-data)?

Presumably you wouldn’t be writing all metadata

Just the relationships necessary for permissions

And the recommended way is to delete them when the resource is deleted or the role is removed

on the dynamic decision part, one thing we were able to do in opa is to take in a full json object into rego and make allow/deny decision based on the json data. if we have similar flexibility in authzed with more standard scripts like a lua would be a nice to have...

That’s explicitly out of scope though

The major benefit of a relationship based model is that you can statically use the graph for decisions

got it on the tidying part...thx...

A fully dynamic policy removes the benefits

That’s why caveats is on relationships: it adds dynamism on top of and in conjunction with the static relationships

i think have to read more on the "caveats" i guess...is there a plan to have article explaining how it will work with some examples?

Yep

It’s currently in development and that issue is merely the starting proposal

But we plan to properly document it soon, once all the pieces are in place to be experimented with

got it...would be nice to know the approach your team is taking...will wait for your article...