What's a typical pattern for assigning metadata in spicedb? I'm thinking of having an

attribute

object type with the object id being the name of the attribute. So something like

user:Bob#has_attr@attribute:verified

Originally I was going to create and remove specific objects based on relational metadata, (e.g. a "deleted" user (boolean flag) gets removed from spicedb) but that creates a lot of sync work that I later realized could be delegated to the permission engine.

What would be the best way to restrict a subject's access to multiple resource when query a SQL database. Would it be to use

LookupResources

and then use an

in

operator within the query?

@User that seems like it will work. Is there some way you think it's lacking or some improvement you would like to see?

@User yep, that would be permissions pre-filtering

an alternative would be permissions post-filtering, where you load a candidate set and then check each item in parallel

depending on which set you think will be bigger

Nah, I'm just wanting a sanity check on my idea.

Do you have an idea on performance when talking about hundreds of thousands resources in the db and thousands related to the subject in question. I know this will be highly implementation specific but what I'm trying to understand is if this is a viable solution at thie scale I described

another way, depending on your goal, would be to have the attribute itself keep track of the users with that attribute

@User I wrote a little bit about ABAC in https://github.com/authzed/spicedb/issues/200#issuecomment-947107907 It contains basically what you've described plus some other common ABAC concepts in other graph systems that we don't necessarily support yet.

Excellent. 👍

It links to a paper that's an excellent read for understanding the problem space

@User yeah I think I prefer that style actually.

@User our preliminary tests for lookup at that scale (data/schema dependent) were around ~100ms I believe

Wow... Give yourself a pat on the back

no pats on the back until you verify those numbers with your own data!

Well I can't hold you guys responsible for my architecture! Now it's up to me to leverage the tool correctly

another user who tried to verify the same scale, but where all resources were related to the user ended up with a response time measured in seconds

So in truth, I don't think I would hit the scale I described. I was just asking to be sure I wasn't committing to a design that would be problematic. Our expected max scale would be about 50-100k total resources with a max of around 1k per subject but most likely around 200 per subject

always good to plan to be able to grow to at least the next order of magnitude

Ughhh, scale... Such a kink in my idealistic designs🤣

@User longer term, we're also working on https://github.com/authzed/spicedb/issues/207 which should provide a lightning fast way of retrieving the full list of object IDs accessible for a particular subject and permission via a cache. If/when it is done, it'll likely be tied into LookupResources too, which would just use the cache if available.

hi yall. Glad to be here. I'm evaluating Authzed and want to ask if it support negative permission. For example, every one has access but user foo is banned. I'd like to only have to create relationship for the banned user

@User yep!

you can use the https://docs.authzed.com/reference/schema-lang#--exclusion operator

gotcha. So all users can be part of

member

group and banned user is part of

banned

group. Then access permission is

group#member - group#banned

?