I've got a schema design question. Say I
# spicedb
b
I've got a schema design question. Say I want to model some ABAC type stuff with how reddit users are allowed to interact with subreddits. Community moderators should be able to capture their own community requirements. These requirements may come in the form of "a user is only allowed to change their flair if they have at least 200 community karma". I know I want caveats. I'd want to store the community requirement (200 karma) as context data on a relationship. And given the dynamic nature of the user's karma, I see this being passed in on the request time context. The obvious way to model this is to sync all subreddits and users into spicedb. However, given the scale, cost of backfilling, and concerns of keeping the denormalized subreddit membership data in sync... we'd love to see if there's a lighter way to leverage spiceDB without ingesting the actual users. This small schema is my attempt to dance around this (I'm not in love with it) https://play.authzed.com/s/gNjlcQiVy7wH/schema I'd love to see if the experts here have any other suggestions.
Roughly, the thinking is to get a little meta and define relationships between subreddits->community actions instead of subreddits->users. Then we determine if the actual connection is allowed with the caveat data supplied at request time. It's certainly weird.
I guess another (maybe less confusing) way of thinking of it is I'm basically using some "phony user" with a constant ID. I don't care about this ID because I'd be relying on the request time context to fill in the user attributes. It's still the same hack though https://play.authzed.com/s/StP29y_PkRDb/schema
Also curious how this constant object ID hack would play with caching. I guess I'm assuming that SpiceDB will not cache results across requests if the context differs. Maybe we're just holding it wrong and the answer is to suck it up and ingest the data. (Although I'm worried this other team will go build a bespoke solution if that's the only solution I offer up 😓)
y
if your system is going to be purely ABAC i don't know that i'd reach for spicedb
it shines when you have authorization questions that can be modeled nicely in ReBAC
and if your domain would benefit from doing that sort of modeling, i'd suck it up and ingest your data into spicedb
b
Yeah that’s a fair. I was starting to feel the same way. Maybe they just need a more simple policy engine. There may be some more rebac type stuff if they wanted to model actual community moderators, but I don’t think that’s what they are targeting at this point in time. Thanks for the input!
e
You could also model this pretty straightforwardly with wildcards, which can keep the user data out of SpiceDB in cases like this:
Copy code
definition user {}

caveat minimum_karma(minimum int, current int) {
  current > minimum
}

definition subreddit {
    relation change_flair: user:* with minimum_karma
}
You then just write one relationship for each subreddit to set the minimum values, like:
Copy code
subreddit:funny#change_flair@user:*[minimum_karma:{"minimum":"200"}]
subreddit:pics#change_flair@user:*[minimum_karma:{"minimum":"700"}]
and then when you
check
you can send the actual user along and get the answer (or just a placeholder value if you want) The nice thing about doing this is that you can start sending users in checks before you have users in SpiceDB at all. Then later on maybe you want to just store
moderators
in SpiceDB and you can start writing rules like "must have 200 karma to change flair, or be a moderator" here's a quick example: https://play.authzed.com/s/xTHM7JGUulpz/schema
b
Oh cool. Just now seeing this. I’ll pass it along as an option. Thanks!
12 Views