I love reading posts like this because it shows that authorization isn't as niche as it once was. I also empathize with avoiding dependencies when you ship enterprise software for running on-prem; we abused Postgres a lot while serving enterprise customers for Quay before we founded AuthZed/SpiceDB. As an engineer it's your job to decide when is the right time to use a dedicated system or continue to invest in your own.
I can't help but see the similarities in their design to concepts from Zanzibar/SpiceDB, and that's great! It also means if they ever do encounter a situation where the existing system is no longer viable (engineers leave or a new design constraint requires rethinking), they _can_ migrate to a dedicated solution easily.
One trade-off I didn't see acknowledged in this post is the sacrifice in terms of tooling. Dedicated solutions have toolchains for debugging and proving correctness that you can integrate into CI/CD and homegrown solutions can't typically spare the time to also build themselves a nice toolchain.
Maybe it's because I'm not an RBAC expert, but I had a hard time understanding the data model for folders. Are they a subject? And then there's a layered CASL where layers overwrite each other? And the user is an actor?
I thoroughly enjoyed this read. As it states at the beginning: rbac is necessary, yet not sexy. I don't use infiscal, yet this post was quite a good insight. Thanks for sharing it!
> That’s also because we didn’t migrate to a Zanzibar-style system like SpiceDB or OpenFGA. Adopting one would mean rewriting every permission check and asking every self-hosted customer to run another stateful service and introduce breaking changes.
I love reading posts like this because it shows that authorization isn't as niche as it once was. I also empathize with avoiding dependencies when you ship enterprise software for running on-prem; we abused Postgres a lot while serving enterprise customers for Quay before we founded AuthZed/SpiceDB. As an engineer it's your job to decide when is the right time to use a dedicated system or continue to invest in your own.
I can't help but see the similarities in their design to concepts from Zanzibar/SpiceDB, and that's great! It also means if they ever do encounter a situation where the existing system is no longer viable (engineers leave or a new design constraint requires rethinking), they _can_ migrate to a dedicated solution easily.
One trade-off I didn't see acknowledged in this post is the sacrifice in terms of tooling. Dedicated solutions have toolchains for debugging and proving correctness that you can integrate into CI/CD and homegrown solutions can't typically spare the time to also build themselves a nice toolchain.
Maybe they don’t like opt-out telemetry?
Maybe it's because I'm not an RBAC expert, but I had a hard time understanding the data model for folders. Are they a subject? And then there's a layered CASL where layers overwrite each other? And the user is an actor?
The https://casl.js.org/v7/en/ link is dead
edit: fixed now
I thoroughly enjoyed this read. As it states at the beginning: rbac is necessary, yet not sexy. I don't use infiscal, yet this post was quite a good insight. Thanks for sharing it!
I think this is true of security features, and even security teams in general. Only noticed in their absence
But why not Zanzibar?
> That’s also because we didn’t migrate to a Zanzibar-style system like SpiceDB or OpenFGA. Adopting one would mean rewriting every permission check and asking every self-hosted customer to run another stateful service and introduce breaking changes.