https://authzed.com logo
Join Discord
Powered by
I don't want Spice to enforce the "exactly one"-re...
# spicedb
r
I don't want Spice to enforce the "exactly one"-relationship (or any relationship for that matter). I was just setting the scene 🙂 I like your simplification, however products will not always belong to a 'department', sometimes only to an organization, so that'd not necessarily work, however your example definitely inspired me. For now we've talked about specific products, but how about listing products as a whole? Is there some sort of convention for that? Since there's no specific ID. I know that there's no specific definition for the 'id' part to be an actual ID, so would I just choose a convention for constructing arbitrary ids which are guaranteed not to collide? Would I make a definition for a 'product list' entity? Would I reverse that and put it as a permission on the organization (i.e. "does John have permission list_products on organization Y" ? Is there an actual 'best practice' way or is it completely up to the queries how I define it? Example:
Copy code
product:dep_depId#department@department:depId
product_list:depId#department@department:depId
e
> For now we've talked about specific products, but how about listing products as a whole? Is there some sort of convention for that? If you have relationships like your example:


Copy code
product:dep_depId#department@department:depId
Then you can use the LookupResources API (https://buf.build/authzed/api/docs/main/authzed.api.v1#LookupResources) to find all products in a specific department.

 Though one of the nice things about SpiceDB is that you really only have to store the information that you need to authorize against - so you might be better off leaving some of that in your application’s database and only storing relationships you care about for Authz decisions. 
LookupResources
is more useful for “what are all of the products that user X can access” more than “what are all of the products in department Y” (though certainly those concerns can overlap depending on the application)
> I know that there's no specific definition for the 'id' part to be an actual ID, so would I just choose a convention for constructing arbitrary ids which are guaranteed not to collide? 

 You can choose a convention, use uuids, or hash some properties, though it’s often easiest to just reference the primary keys of another datastore (which might themselves be uuids, etc).
> Would I make a definition for a 'product list' entity? Would I reverse that and put it as a permission on the organization (i.e. "does John have permission list_products on organization Y" ? Is there an actual 'best practice' way or is it completely up to the queries how I define it? 

 This is more up to how you expect to need to authorize things and what you’re trying to optimize. ACL filtering via 
Lookup
is fast (and we have some plans (https://github.com/authzed/spicedb/issues/207) to make it even faster) but it always requires more computation than a simple 
Check
- so if your application allows for a 
list
permission against an entire set of objects, that will be faster to compute in general.
r
Thanks a bunch, @User, that was really helpful - the way I hear it is that there's really no rules, rather many degrees of freedom to design the schema to suit the application needs. > so you might be better off leaving some of that in your application’s database and only storing relationships you care about for Authz decisions It's very comforting that you mention this specific thing, because that was one of my main concerns; would I be "doing it wrong" if I didn't mirror every single entity to SpiceDB? And the answer is obviously no.
j
definitely no
the recommendation is to mirror what you need, and only what you need
and sometimes, you may not even need to mirror
for example, if you have groups or teams, their membership could be solely in SpiceDB
no need to keep it in your DB unless you need to access it for something besides permissions
r
Hm, that's an interesting point. I could keep user groups and users in a classic DB structure, but instead of the group_members pivot table, SpiceDB could be the source of truth for memberships
Thats an interesting thought
j
yep
r
And also solves another headache i've had; mirroring group memberships, effectively working against the 'single source of truth' principle. What made me dismiss that option in the beginning was seeing Zanzibar as being primarily meant for the 'check' feature, and the other (expand, lookup ect) supposed to be used less.
But I see now that it's much more than that
j
definitely used less
but still highly important
for example, we drive the Authzed.com management permissions panels from 
Expand
that way, we don't need to keep the permissions relationships in two places
r
Yup, obviously check is going to be used much, but the other features are super useful for visualizing (derived) permissions to administrators
Makes sense
Is there a concept of composition or inheritance in the SpiceDB Schema?
j
permission
expressions
so if you had, say
r
We have somewhere around 30-50 entity types which all share the same 4 CRUD permission scheme + some special ones for some of the entity types
j
Copy code
definition resource {
  relation editor: user
  relation viewer: user

  permission view = viewer + editor
}
r
Yup, that's awesome, but I was thinking cross-definition
j
define a single 
definition entity {
?
r
Let me provide an example:
j
k
r
Copy code
mixin crud {
  relation editor: user
  relation viewer: user
  permission create = editor
  permission read = editor + viewer
  permission update = editor
  permission delete = editor
}

definition book {
   mixin crud
}

definition car {
  mixin crud 
}

definition movie {
  mixin crud 
}
I have mixed (haha) feelings about duplicating the relations and permissions to each definition; it's quite explicit and doesn't cause ugly side-effects when wanting to modify a single definition
j
yeah, we've considered it
the recommendation (today) is to just have a 
crud
resource type if it is going to share the same model
r
but yeah, it's duplicate
RIght, yeah so the thing is that some definitions might need additive relations:
Copy code
definition car {
  mixin crud 
  relation owner : user
}
But I see where you're going with the crud resource
j
yeah
its definitely been raised
j
I have opened this issue to track this request and others like it: https://github.com/authzed/spicedb/issues/224
for now, could you use jinja/moustache/etc to generate your schemas?
r
Yeah templating/generating was actually my immediate thought, and I'm probably going to be doing that anyway in order to be able to agnostically distribute entity/action names etc
So that's a good solution - depending on what feedback you get from other maintainers, I'd accept the argument that mixins/inheritance is actually out of the scope for SpiceDB and never will be implemented
I do, however, like the "crudable" twist you added. Provides some abstraction
20 Views
PreviousNext
Powered by