Open dberesford opened 5 years ago
This is an interesting one and something that touches on recent work I've been doing with fastify-casbin plugins. Casbin being an authorization system we've been experimenting with, being able to identify resources automatically in a fastify app is something useful and in fact something I've done in the rest plugin, which extracts resource (sub, obj, act) from the request automatically.
As to the question about whether udaru can be used to mimic Hasura's role based permission model (which is in fairness an extended version of RBAC, in fact it's probably ABAC) I am not sure, but Casbin can via expression evaluation.
In practice, a rule, besides being a perfect match, could also evaluate code dynamically, see example here. I think this is very powerful and definitely something we should investigate further.
A common pattern we see with udaru is
http request -> gateway -> microservice
, where the gateway determines (by whatever means) what the user, action and resource are in the request handler. It then calls udaru to see if the user can access or not, and if they can proxy on to the microservice. It is relatively straight forward for the request handler to determine the action and resource from the request endpoint as the it's usually specific to the url and the handler has all the context.Need to POC a similar pattern for Graphql calls, i.e.
/graphql request -> gateway -> graphql service
.This is tricky as the context is not in the request itself (all graphql calls are via a single
/graphql
endpoint) but in the graphql query itself. The ask here is to demo best practice to parse the graphql body and show how actions and resources could be pulled out of the query. Queries or Mutations are easy to identify, also operation name if it's set, and beyond that it gets a little messy as your iterating through generic variables.Worth checking out how fastify does this under the hood: https://github.com/mcollina/fastify-gql#post-graphql
The bigger POC here is to see if we can use lambda at edge as the "gateway" that does the udaru permission checking before proxying through to Hasura. The experiment here is to see if udaru can be used as an alternative to Hasura's role base permission system.