Using something like this for centralized authorization across services works well for binary access control decisions.
But the problem that remains is "authorized search" in an efficient way. Asking permify what resources a user can access and then query the app postgres db with "WHERE resource_id IN ( {list}, {with}, {many}, {IDs}, ... )" does not scale well. How to solve this?
While there are a variety of approaches, currently our recommended solution is to use the Watch API[1] to create Leopard-style (matrix) indexes in the client’s database to enable efficient permission filtering using schema and YAML-based index definitions.
We started down the path of building an example watch consumer[2] but both the team and the interested community members were pulled off it for reasons, but not for technical ones.
This FAQ may be helpful to learn more about leopard indexes[3].
Using something like this for centralized authorization across services works well for binary access control decisions.
But the problem that remains is "authorized search" in an efficient way. Asking permify what resources a user can access and then query the app postgres db with "WHERE resource_id IN ( {list}, {with}, {many}, {IDs}, ... )" does not scale well. How to solve this?
We've had community members bring this up[0].
While there are a variety of approaches, currently our recommended solution is to use the Watch API[1] to create Leopard-style (matrix) indexes in the client’s database to enable efficient permission filtering using schema and YAML-based index definitions.
We started down the path of building an example watch consumer[2] but both the team and the interested community members were pulled off it for reasons, but not for technical ones.
This FAQ may be helpful to learn more about leopard indexes[3].
0: https://github.com/Permify/permify/issues/2681
1: https://fusionauth.io/permify-docs/api-reference/watch/watch...
2: https://github.com/Permify/indexer
3: http://nil.csail.mit.edu/6.5840/2023/papers/zanzibar-faq.txt