Remix.run Logo
We Built an Authorization Engine That the Fortune 100 Bet On(technology.org)
6 points by mooreds 12 hours ago | 2 comments
seymon 8 hours ago | parent [-]

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?

mooreds an hour ago | parent [-]

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