Hello all! As always thanks for prompt answers to ...
# help
r
Hello all! As always thanks for prompt answers to questions here. I'm currently sharing around Cerbos as a solution and have been able to field a lot of questions, but one came up that I don't have any insight into: Most use-cases I've run into are perfectly suited for making a request and then authorizing each resource, But in some cases, like queries to ElasticSearch, that isn't possible (prevents pagination, etc.) What's the Cerbos way of handling a use-case like this?
a
Hey Ryan
You have run into the big shift when moving to decoupled authorization, handling the listing/filtering instances of a resource. The Cerbos approach to this is a partial evaluation of policy using what we call a Query Plan. This is a secondary endpoint which returns a set of filters that need to be met to return just the instances of a resource that a given principal would have permissions to. You read more about this here https://docs.cerbos.dev/cerbos/latest/api/index.html#resources-query-plan
r
I see, so conceptually, let's say for some sort of resource search or bulk approval process: 1. App logic receives principal information 2. App calls Cerbos with the principal, action, and resource kind 3. Cerbos returns the AST of how to filter 4. It's up to the app to interpret that and then execute the search appropriately
a
That’s correct!
We have prebuilt adapters for Prisma and SQLAlchmey ORMs if you happen to use those https://github.com/cerbos/query-plan-adapters
r
I can see the value in this approach! It sounds like we'd have to write our own ElasticSearch query plan adapter in the meantime, are there any query plan adapters on a roadmap? They seem to share a fair amount of logic so I'm not too concerned about it, our cases are pretty manageable rn
s
Queryplan adapters roadmap would be nice to have visibility on- yes! We use .net Entity Framework, so +1 on that one.
a
We are open to suggestions (and PRs 😜) - which do you need @Ryan Killeen ?