Authorization within filtered, sorted, and paged lists

[jonathaneckman]

I have read Search with Permissions but am still struggling to see an efficient way to handle this basic use case. Say I have an endpoint in my apps API that allows the client to request a list of projects that can be paged, sorted, and filtered. It is rendered on the page as a table with:

1. A link the user can click to open a project details page (view).
2. A button the user can click to open a project edit page (edit).
3. A button the user can click to delete the project (delete).

Only my database has the context to know how to page, filter, and sort. Only my FGA store has the context to know whether an item in the results can be viewed by the user.

Below are your recommended approaches and where I'm getting stuck in each.

Option 1: Search, Then Check

1. Filter, sort, and page in my database. Lets say the client requested the 2nd page of results with a 100 item page size.
2. Call /check to verify the user can see each of the results, so 100 checks will be performed in a batch.
3. Lets say of the 100 items, the user could only see 80 of them.
4. Repeat from 1, but requesting a page size of 20.
5. Potentially repeat until I have paged my entire projects table to learn the user doesn't have access to a full 100 items??
6. Either during the /check calls or with the final "viewable" list in hand, now call ListRelations using the SDK to get the permissions array for each individual item (ex: can_edit and can_delete).

To prevent step 5, I know I could filter my db query so it mimics the relationships defined in the tuples that are evaluated during the checks, but this feels like complexity would quickly accumulate within my queries and business logic. This flavor of complexity is the very thing I had hoped FGA would eliminate.

Option 2: Build A Local Index From Changes Endpoint, Search, Then Check

To build an index, I'd run this process at some frequency or triggered by some event:

1. Call the /changes API. This does not return concentric relationships. Only a list of changes to tuples I have added and removed from my store.
2. Call /expand for each of these changed tuples to get the concentric relationships. It is not clear how this would work. See question below.
3. With this data, update my index. In my case, which is list filtering and sorting and not search, I imagine this would be a permissions table I store these in that relate to the relevant entities in my database.

Now with these permissions in my database, I can very easily query for a filtered, sorted, paged, and authorized list from my own database:

1. Apply the client provided filter, sort, and paging parameters.
2. Apply a filter to exclude any item the user cannot see, which is known from the data synced to the permissions table in my db from my FGA store.
3. Include additional things from my permissions table for each result as needed, such as an array that would include can_edit and can_delete.

I see /expand is recommended to expand the changed tuples in your docs to get the concentric relationships. Say I have a model where:

1. A user is an admin of the system.
2. The system has orgs.
3. Orgs have projects.
4. Projects have tasks.
5. The system admin user can view everything via their direct relationship to the system and concentric relationships to all other types.

The /changes endpoint would alert me that user:X now has admin relation on system:my-system. Would I have to then use expand to walk the graph down to the lowest level "tasks" type? Is there an easier way?

Ideal solution?

It seems that to solve this, 1 of 2 things needs to be true:

1. The FGA store needs the context of my apps db.
2. My apps db needs context of the permissions from my FGA store.

The latter feels the most correct. Oso seems to be trying to solve this with Distributed Authorization. A solution in my (currently FGA amateur) mind would be something like:

1. A webhook or a /changes endpoint I can poll where FGA could send a list of flattened tuples (concentric and direct) to detect when a relationship between a user and a type has changed.
2. My application receives and stores them to build the "index" or permissions table described in Option 2.

That said, even this feels less than ideal because 1 change at a high level (like adding or removing a system admin) could trigger a new tuple for every row in my database at a lower level (such as tasks from my example above).

Help

At the moment, I don't see how either options would be viable for my use case. Option 1 feels possible but incredibly inefficient and Option 2 doesn't seem possible unless I know exactly what a change to a direct relationship tuple means within the context of my application.

I am new to FGA and trying to ramp up quickly, but am hitting this wall. Help me out. What am I missing?

[bytefish]

@jonathaneckman Thanks for the link to the Oso article and your thoughts. I feel validated, that I am not the only one having problems integrating it. May I ask, what conclusions you’ve arrived at?

As for me, I think building a Local Index and using it to join the local data might be the way to go. @aaguiarz It would be really useful if there was a minimal example how such a Local Index could be built using the /changes endpoint and the Expand API. I would also appreciate Pseudo Code. 😌