Authorization really should be unasked as a question. Instead, we should consider building capability-safe systems where authorization is implicit; possession of a capability is equivalent to permission for invoking that capability.
It is devilishly complicated to design authorization policies that you know are bulletproof in most of the AuthZ languages. I haven’t looked into SpiceDB/Zanzibar but I suspect it has the same problem. Unless you can GUARANTEE that a typo in an AuthZ policy won’t leave your door wide open for attackers, uptake will be very slow.
This is definitely true for many systems – one of the nice aspects of more modern approaches to authorization is that you can effectively test/model check your systems before deployment. For example, SpiceDB allows folks to check positive/negative assertions and exhaustive relationships using the Playground or GitHub Actions. Outside of proving just the model, SpiceDB also supports a mode specifically for running application integration tests.
The reality is lots of folks are building this stuff themselves and they are not experts. Also very few organizations have the budget to dedicated engineering to only solving this problem, so they’re unlikely to have priorities to build all of the tooling you need to gain confidence in your permissions model.
I think it is difficult to discuss authorization systems without discussing
provisioning systems
role engineering
Role engineering is sort of like establishing the ‘type’ model (roles) and the maintaining the type model on ongoing basis. These systems include role harvesting, policy harvesting, and then governance. Some times this is called Policy modeling.
Provisioning system is where basic checking is done, for example that Role A and Role M must not be combined together. Obviously provisioning does a lot more (it is a workflow to identify, assign, check and approve for roles).
I cannot find quickly links to the systems implementing the above, so apologies for that. I have been out of the field for a number of years, so not current.
WRT
Permissions are inflexible
Certainly, that’s the case if they are static. But a typical authorization system would be using a rule engine at a PDP (policy decision point). To provide rule-based decision flexibility.
Authorization really should be unasked as a question. Instead, we should consider building capability-safe systems where authorization is implicit; possession of a capability is equivalent to permission for invoking that capability.
It is devilishly complicated to design authorization policies that you know are bulletproof in most of the AuthZ languages. I haven’t looked into SpiceDB/Zanzibar but I suspect it has the same problem. Unless you can GUARANTEE that a typo in an AuthZ policy won’t leave your door wide open for attackers, uptake will be very slow.
This is definitely true for many systems – one of the nice aspects of more modern approaches to authorization is that you can effectively test/model check your systems before deployment. For example, SpiceDB allows folks to check positive/negative assertions and exhaustive relationships using the Playground or GitHub Actions. Outside of proving just the model, SpiceDB also supports a mode specifically for running application integration tests.
The reality is lots of folks are building this stuff themselves and they are not experts. Also very few organizations have the budget to dedicated engineering to only solving this problem, so they’re unlikely to have priorities to build all of the tooling you need to gain confidence in your permissions model.
A primer on modern authorization systems
I think it is difficult to discuss authorization systems without discussing
Role engineering is sort of like establishing the ‘type’ model (roles) and the maintaining the type model on ongoing basis. These systems include role harvesting, policy harvesting, and then governance. Some times this is called Policy modeling.
Provisioning system is where basic checking is done, for example that Role A and Role M must not be combined together. Obviously provisioning does a lot more (it is a workflow to identify, assign, check and approve for roles).
I cannot find quickly links to the systems implementing the above, so apologies for that. I have been out of the field for a number of years, so not current.
WRT
The PDPs are also used to inject filtering criteria into SQL queries (to push authorization rules down to the query engines). Eg (in 2011) : https://axiomatics.com/news/press-releases/axiomatics-releases-new-reverse-query-authorization-product-a-breakthrough-innovation-for-authorization-services