Open rosshadden opened 4 years ago
~Do we want to define some default mapping or a directive that maps queries and mutations to actions? Like do we want by default to map the name of the query/mutation to the action name directly? For example: graphql query primaryShopId
maps to authz action 'primaryShopId`.~
Nevermind I see there's an explicit `action:' annotation parameter
Here are a smattering of thoughts:
What
GraphQL as a spec supports custom directives. This is how Apollo is able to add things like
@key
and@external
.We can leverage our own custom directive(s) to better support authorization (for example). The linked docs have an example section on authorization, but we can do something even better since we have our authorization already abstracted into its own service.
Inside our schemas we can annotate types, queries, and mutations with things like their resource path, which would let us implement gateway-level authorization.
For example:
Some notes on the above:
ref
.@affects
@concerns
@hook
@involves
@policy
@ref
@reference
@uses
@bind
@connect
@entity
isn't really well thought-out or an official idea, I was just spitballing some other things we could annotate.@key
is a directive added and used by Apollo Federation itself.getPricebook
) that works with one resource. This will be our most common case.getPricebookEntry
) is an example that works with two resources, as clients are able to request fields on pricebooks as well.getPricebookEntry
only enforced rules on pricebook-entries unless clients request fields within pricebooks, with this plan I suppose the workflow would be to only annotate with the former, and optionally enforce the latter in the pricing service itself.How
The work required for this issue:
buildFederatedSchemas
complains that you are using an unregistered directive. We still want individual services to be able to run independently of the federation, so we need to either figure out why, or perhaps define the directives in each service's schema.@ref
(in concept---can be called anything that makes sense)Why
This lets us do some really cool things. It will let us go from have 0% of our authorization checks at the gateway level and 100% at the app level to having most of them (by far) at the gateway level. This means we will be able to determine whether users are authorized to perform certain actions before we even call out to the app in question.