Thanks Joey. So say we has a self-service access for customers to administer their org membership. This service would modify data in SpiceDB. Likewise when we added a new customer account, that account would be added to SpiceDB. This is is different than say a Rego policy that says user must have orgid that matches the resources' orgid in that SpiceDB has knowledge of all the attributes and not just of rules pertaining to those attributes. I think ?

correct!

you'd use the WriteRelationships call to update the relationships in SpiceDB; after that point, since the data is managed by SpiceDB, it can aggressively cache and use the data to provide other capabilities too such as reverse walking

Quite different mindset than the policy approach. I see where the OPA and SpiceDB integration gets interesting because they are completely different. One would also need to insert the resources on the SpiceDB graph too right? Such as API paths? DB columns/roles? SpiceDB ends up knowing all ... are there architectural coupling concerns?

only the resources and how they relate to one another for answering permission questions; no need to write relationships or resources that are not used for answering permission questions

so typically this involves: users, their roles, and maybe nesting like organizations, namespaces, or folders

ya, thats the other challenge I have. So much flexibility .... for me to do it wrong 😄 Know of blueprints for multi-tenant B2B SaaS?

yeah, we have some examples schemas in our consistency tests, including one for our previous multi-tenant B2B SaaS: https://github.com/authzed/spicedb/blob/main/internal/services/testconfigs/quay.yaml

I'd recommend loading that into the playground at play.authzed.com and then modifying as you go along

we also have a bunch of other schema examples too if you're interested

Just read about the playground running spicedb in the browser - way cool. @Joey thanks for the orientation!

anytime! don't hesitate to ping with further questions

added the debug command to the docs: https://docs.authzed.com/guides/debugging

@Joey For your attention 🙂

one thing that we're running into is a desire for audit metadata associated with individual relations - an authorizing user, write time, that kind of thing. we wouldn't need or want them to be a part of check requests - the idea is more that it would be attached to the relation during write and visible in a

WatchService

stream such that we could go dump it into an audit topic in kafka. I don't think we'd need to see the metadata anywhere else. it would mean that we don't need to worry about maintaining this information in separate streams (e.g. a second database that we need to sync with SpiceDB). is this possible/desired/somewhere on the roadmap?

We have talked about it internally. If you're interested in seeing it become a reality, can you write a proposal in GitHub?

some other proposals: https://github.com/authzed/spicedb/issues?q=is%3Aissue+is%3Aopen+proposal

The upcoming "caveated relationship" functionality could support this, and it already shows up in

Watch

(this functionality is still WIP, but is already in

main

). The downside is that data would be injected at request time into the caveat evaluation engine, thus incurring unnecessary overhead (but only if a caveat is set in the relationship).

see https://buf.build/authzed/api/docs/main:authzed.api.v1#authzed.api.v1.ContextualizedCaveat

The upcoming caveated relationship

So lets say, you have a group hierarchy in Active directory to govern users access genereally, like userA is author in department B. But use SpiceDB for additionel ABAC like Document C is shared with user D. This require some copy-model some of the AD-groups in SpiceDB. Then which pattern would be smart to use to keep the internal SpiceDB realation in sync as users may switch AD-groups ( for instance if user A switch department) ? do you keep an AD copy locally and whenever a change occur traverse all relevant user relations for updates, which sound quite errorprone or is there a better pattern ?

I think SCIM is the answer for this. We have it on our backlog to write a general purpose SCIM adapter, but it will likely be a commercial offering and I don’t know when it will happen.

I like everything that this gives me except not running against a real data store. in particular for the CI case. That setup by is very nature is ephemeral. If there we are doing something that may give spicedb or its backing data store problems, I'd like to find them in CI before going to production. what would it look like to make the testing setup also use the configured data store?

you'd need to spin up a real datastore and a real SpiceDB cluster

we do that

then you should be fine to make API calls against it

in testing mode?

it would be a real mode

what would you be looking for re:testing mode?