https://authzed.com logo
Join Discord
Powered by
Hey guys, I had a question about
# spicedb
k
Hey guys, I had a question about modeling. Lets say I have a model like this: definition user {} definition document { } and I want , in some cases , to give to a specific user access to all documents, without having to add all ducument in tuples(since there are milions of them). one option I thought : definition user { relation documentOwner : document permission owner = documentOwner } definition document { } And adding wildcard like this: user:1 documentOwner document:* but this doesnt seem scalable as other entities are added, then the permissions in user enetity would get a lot? Is this a correct pattern? important to note that I dont want to add all realtions to user:1 and document:x , as documents are millions and I dont want to sync all of them just for this use case
v
The requirement of "not syncing all the documents" makes it difficult to implement. A document must exist in order to compute some permission. Typically you do this by creating a container to all documents, and make the user has permission at level of the container:
Copy code
definition user {}

definition document {
  relation parent: folder
  relation viewer: user
  
  permission view = parent->view + viewer 
}

definition folder {
  relation viewer: user

  permission view = viewer
}
Inverting and using wildcards is a potential way, but it inverts the relation between objects and will become challenging to evolve. As a consequence you have two ways to check for the same:
Copy code
definition user {
  relation admin: document:*
}

definition document {
  relation viewer: user
  
  permission view = viewer 
}
What this means is that now you have two ways to check for stuff - one to check if user has access to individual resources - one to check if user has access to all resources (inverted)
A way would be to create a singleton document, like 
ALL_DOCUMENTS
, which is a document that denotes all documents, and grant permission over that. Another one would be to create the higher level container like 
definition platform
and grant permission to the user there, and then check if they have access via that resource
k
Thanks for the response. Which one would you suggest? Singleton document or container entity
v
Singleton document since it would look like the same kind of query as documents with individual prrmissions
k
Im not sure this fulfills our requirement,because in the case of later checking if user:1 owns document:4 (this document doesnt exist) it would return false, even if that user owns ALL_DOCUMENTS. Also syncing all of them would not be a option since its millions per month. How do you guys handle these cases?
v
how can possibly SpiceDB make an authorization decision over a resource it's not aware of?
Centralizing data is fundamental to SpiceDB's design
and whan I suggested is not to check 
user:1 view document:4
but 
user:1 view ALL_DOCUMENTS
and OR that with 
user:1 view document:4
(basically use the 
CheckBulk
API to do 1 call with both checks)
please note this is not the recommended way, because you are moving authorization logic to the client
but without centralizing data into SpiceDB I'm not sure what else to recommend
We are planning to work on something potentially called "simulated/provisional updates" that would allow you to pass relationships as part of the request, that would likely address your problem, but you basically miss all the nice properties of SpiceDB. The use-case we provide it for is for folks that are in the process of migrating the data to SpiceDB, so they can start relying on it without having to move all the data upfront
PreviousNext
Powered by