Query plan: how to evaluate ast json response?

[vichugunov]

Hello cerbos community,

First, thank you for the great product.
I want to use response for query plan (https://docs.cerbos.dev/cerbos/latest/api/index.html#resources-query-plan) in order to:

• verify that action is allowed by pre-checking principal attributes and this plan response
• build my own DB filters out of it

Is there a way to evaluate this ast condition expressions, given in json response? If I could reconstruct it back either to ast or something else I can evaluate on my own, it would be great to see which tools are available.

[dbuduev]

Is there a way to evaluate this ast condition expressions, given in json response?

TLDR: Not now, but something of this kind is coming - if I got what you mean.

I'd like to understand your use case better. In order to evaluate the AST returned by the planner, you need to provide resource attributes. That means you have both the principal and the resource attributes to use the CheckResources API.

Do you want to avoid (remote) calls to CheckResources API and evaluate the policy locally?

[vichugunov]

Yes, the idea is to make less calls to CheckResources API for each individual resource, if it was a request to obtain collection of resources. Since the business logic of matching principal <-> resource attributes lives in the policy, we need to obtain it via PlanResources before making a query to the database (or another actor).

Use case 1: Get all resources that are allowed for the provided principal and the action.

In this case I want to have one request to PlanResources, then transform this response into DB query. Problem comes if some complex policies are saved and some functions (e.g. lambda expressions or get-field/set-field struct operators) are not easy to interpret. Some expressions and techniques help to simplify PlanResources response, but at some point we could hit the wall and not able to convert it to ORM/Plain SQL statements.

Use case 1.2: Combine with provided user filters
Consider the case when user provided some filters and based on it we need to obtain the data.
We need to make a request to PlanResources and evaluate if allowed attributes have any intersection with the filters or not.
If the intersection exists, we need to make a combined query to obtain the data (user filters + allowed resource attributes).

I thought even on having a stored procedure that I can feed with this response and then apply it to a dataset, but this won't fit for all cases, since many tables have different structure (and some even outside of database boundaries).
In mongo there're aggregation pipelines, that are applied to a dataset: https://www.mongodb.com/docs/manual/core/aggregation-pipeline/

So either we need to transform this response to something DB will understand and/or evaluate our provided filters and mix/match with allowed resource attributes.

Actually this PlanResources was so inspiring (comparing to Casbin for instance), but I can't find an easy way to use it for these cases without writing my own PlanResponse parser + evaluator, which seem tedious.

[dbuduev]

Yes, the idea is to make less calls to CheckResources API for each individual resource, if it was a request to obtain collection of resources.

You can batch up to 50 resources in a single request. This number is also configurable. Our performance tests show that CheckResource API is extremely responsive. The exact latency number depends on many factors. Are you targeting any particular latency value?

Use case 1: Get all resources that are allowed for the provided principal and the action.

Problem comes if some complex policies are saved and some functions (e.g. lambda expressions or get-field/set-field struct operators) are not easy to interpret.

We aim to eliminate these where possible. Here is a resolved issue, a temporary workaround and two subsequent PRs. Please raise an issue if this doesn't solve your problem.

but at some point we could hit the wall and not able to convert it to ORM/Plain SQL statements.

Just a thought. You can discard parts of the AST, which are too complex for SQL, and use the CheckResource API after selecting data from DB. You may skip the CheckResource API calls if nothing was discarded.

Use case 1.2: Combine with provided user filters

If the user filters are exact values of resource attributes, you can do it with the existing PlanResources API.

To summarise my understanding of your use case:
You select data from the database by applying user filters. You would like to add authorisation filters, but sometimes you can't get a SQL from the AST produced by the PlanResources API (aka the planner AST).

You are looking for a way to merge user filters with the planner AST. Do you want to get a (combined) function that you can execute locally? Or do you want to get a combined AST so you have a better chance of converting it to SQL? Both?

[vichugunov]

You can batch up to 50 resources in a single request.

That in any case I want to avoid to be as close to DB queries as possible. I consider this example from refine.dev (https://refine.dev/docs/examples/access-control/cerbos/) as a no-go because it makes clients to query everything all the time, making them aware of the authorization logic. In case we would want to change this part, we have to adjust every client to not query it per resource, and that's pretty bad. Ideally I want to ship a package that could get all principal details, obtain from the outside known resource attributes, do a query to PlanRequests and let clients construct their queries based on it. This will be more stable and close to any other concept. Or even move this PIP to the Proxy Service, that is connected to database, that will prepare the same payloads to Cerbos.

Please raise an issue if this doesn't solve your problem.

Yep, I use these techniques and they help so far. Anyway, I'm searching for something to be sure that we won't have something not analyzed properly.

Just a thought. You can discard parts of the AST, which are too complex for SQL, and use the CheckResource API after selecting data from DB. You may skip the CheckResource API calls if nothing was discarded.

I like this idea, because in this case we always have a fallback to verify it. In any way we will configure alerts on our end if we find something that we can't interpret/convert and follow this advice or raise an issue.

If the user filters are exact values of resource attributes, you can do it with the existing PlanResources API.

Yep, as long as they're compatible they can be translated, but it's sometimes more business-logic oriented, that has nothing in common with attributes stored with resources. In this case it's unavoidable to have a logic, combined with AST response and that's built on top of it.

You are looking for a way to merge user filters with the planner AST. Do you want to get a (combined) function that you can
execute locally? Or do you want to get a combined AST so you have a better chance of converting it to SQL? Both?

Ideally both. I'd say the first one will be sufficient - combined function that I can execute (and use it alongside with custom business logic if required). Just to eliminate the uncertainty if something couldn't be easily transformed into SQL and to make requests to checkResource api in batches.

Second one I know could be more challenging, but developers would definitely benefit, if, for instance, you could provide an AST and devs could find some ways to transform it (and extend it if needed). Because at the very end all consumers have to do this: interpret the response of PlanResources and make some queries to DB and/or transform it to a set of conditions that they can evaluate.

[dbuduev]

I consider this example from refine.dev (https://refine.dev/docs/examples/access-control/cerbos/) as a no-go because it makes clients to query everything all the time, making them aware of the authorization logic.

Soon we will release something to change this. Sorry, I can't tell more now.

I'd say the first one will be sufficient - combined function that I can execute (and use it alongside with custom business logic if required).

I think the aforementioned feature will cover this situation as well.

Second one I know could be more challenging, but developers would definitely benefit, if, for instance, you could provide an AST and devs could find some ways to transform it (and extend it if needed).

That's an interesting idea. We will think about it. Thanks.

Edit: s/realise/release/