Request: ABAC Recipe and GraphQL for biscuit?

[StevenACoffman]

Hi! I am the maintainer of https://github.com/99designs/gqlgen, and I would like to implement a biscuit plugin for GraphQL Authorization for gqlgen (in Go), somewhat similar to https://github.com/apollographql/router-biscuit-plugin

One thing I'm struggling with is that although there is an RBAC recipe, there's not an ABAC recipe for biscuit. Are you aware of someone who has done something similar?

Also, biscuit specifically uses datalog, and I'm already using GraphQL, and they are both Graph query languages.

Datalog describes recursive conjunctive queries on hypergraphs (relational model) without or with limited negation, and thus return a set or bag of hypergraph edges.

GraphQL queries describe Tree unfoldings of graphs, and thus return trees.

I was wondering if there was a way I could translate between datalog and GraphQL (or vice versa) for biscuit for simple auth evaluation.

For instance, DGraph allows Graph-Based Access Control using @auth directives, and I'd like to do something similar. Any thoughts?

[StevenACoffman]

I was particularly interested in if @Geal had any thoughts about datalog/graphql

[Geal]

that should be interesting!

One thing I'm struggling with is that although there is an RBAC recipe, there's not an ABAC recipe for biscuit

Biscuit is naturally leaning towards ABAC, you just need to expose whatever attribute you need from the request context, by adding facts representing them (cf https://github.com/apollographql/router-biscuit-plugin/blob/main/user/src/main.rs#L97 ). You can then add predicates over those attributes using datalog expressions.
I am not sure automatic translation between graphql and datalog would be straightforward, but there could be a middle ground. In the Apollo Router authorization, you use directives that indicate conditions that must be met to access a field or type. Those conditions do not need to map purely to GraphQL, maybe they need instead to ask questions from the current type (values of other fields, etc). So instead of translating the query directly from graphql to datalog, it becomes more about extracting the policies relevant to a query, then exposing local data from the graph to those policies.
The main issue you will encounter is how to expose that data, because the engine is not designed to hold a mirror entity to every entity in your graph (the way a Zanzibar like solution would do), it is meant to be temporary, for the time of request execution. So the challenge is in loading enough data in the engine to authorize the query, but not load the entire graph.

If you want, we could do a call so I can explore the topic a bit with you, maybe we can find a good way to represent the policies you want