I'm currently exploring possibilities to adopt e.g., SpiceDB to fulfull the overall Zanzibar use case as central authorization service across multiple products and services. This doesn't only come down to the ability to scale with the load, but also operational management. As of today SpiceDB loads the whole schema in one operation with no direct ability to segregate ownership for different resource types aligned with products/services and matching lifecycle management for the same. This would be a necessity to cover such an enterprise use case though, wouldn't it? The individual product teams should have ownership over their app authorization schema, but it needs to fit into the overall enterprise schema as well - requiring matching assertions to ensure cross app relations will not break throughout individual schema updates and versioning. I've seen openFGA having some support in this direction, but I don't want to go into comparing different solutions here. Another thing would be a custom role and conditions use case, exposed to be managed by end-users, similar to what is displayed in Google Cloud IAM. Here users can define their own conditions based on CEL that seem to be directly added to the role binding and this would also be use case very relevant in the B2B environment we operate in. As far as I've seen, caveats need to be predefined in the schema which isn't really feasible in such a case, even though you can supply relation or request based data as context. What is your take on these?

Hi 👋 1. we agree, and we are tracking this in https://github.com/authzed/spicedb/issues/1437, please chime in with your requirements 2. this is already done with SpiceDB Caveats, and it's implemented with CEL

Thanks, I've seen the issue and will probably join the discussion. I'm not sure about the caveats though - the caveats are defined as a function in the schema and can be referenced in thge relation definition. What I haven't seen is if I can define an arbitrary expression and tie it to a specific relation tuple. Essentially this would open up a full CEL editor for users of the application to specify e.g. I want to share certain content under my defined constraints only. So the definition of the caveat itself can't be part of the schema as it's not known until a user creates this specific caveat for a specific relation. Maybe I'm missing something though 🤷‍♂️

I see what you mean. We call those dynamic caveats. We actually have implemented that internally to support Authzed Enterprise FGAM

I agree, but in those cases auditing is then also something that needs to be exposed to the end-user organization anyway as they want to enforce their security policies on top of your own product auth model. It's more specific to those platform use cases of course.

👍 for dynamic caveats. I have the same issues at @TKCen - different end-user orgs with their own security policies. I'm working around it at present by representing the logic of the policies themselves as relationships in the spicedb graph pointing to attributes of customer entities, and using internal entities to implement and / or. But it's complex, and has limited expressivity. A CEL argument type, I think, would make for a much simpler implementation.

agreed. For scenarios where the application builds dynamically authorization policies on top of SpiceDB, CEL expressions make sense