@authentication filter operation

[jroith]

I created a bug a few months ago for the @auth directive and hoped the issue would be resolved with the new directive, but this is not the case. Basically, authorization can be bypassed to read any protected type or field by checking fields using filters on related types.

Here is an example:

type Foo
  @authorization(
    validate: [{ where: { jwt: { roles_INCLUDES: "READ_FOO" } } }]
  )
 {
  name: String!
}

type Bar {
  test: String
  foo: Foo @relationship(type: "OF_FOO", direction: OUT)
}

So a direct query like { foos { name }} would fail as expected.
But it is possible to run: { bars(where: { foo: { name_STARTS_WITH: "a" }}) { test }}
This query should be rejected - it should not be possible to read name indirectly this way. I would expect an error to be thrown whenever "foo" appears in this filter and it does not meet the requirements. If this is not technically possible then the query should still be unconditionally rejected if "foo" occurs in the filter at all, rather than leaking protected data.

The query would also fails with a "filter" authorization on Foo. It does not work both for related objects and related lists.

[neo4j-team-graphql]

Many thanks for raising this bug report @jroith. 🐛 We will now attempt to reproduce the bug based on the steps you have provided.

Please ensure that you've provided the necessary information for a minimal reproduction, including but not limited to:

• Type definitions
• Resolvers
• Query and/or Mutation (or multiple) needed to reproduce

If you have a support agreement with Neo4j, please link this GitHub issue to a new or existing Zendesk ticket.

Thanks again! 🙏

[neo4j-team-graphql]

Many thanks for raising this bug report @jroith. 🐛 We will now attempt to reproduce the bug based on the steps you have provided.

Please ensure that you've provided the necessary information for a minimal reproduction, including but not limited to:

• Type definitions
• Resolvers
• Query and/or Mutation (or multiple) needed to reproduce

If you have a support agreement with Neo4j, please link this GitHub issue to a new or existing Zendesk ticket.

Thanks again! 🙏

[darrellwarde]

Hey @jroith, we just discussed this one. The conclusion is we all pretty much agree that this should be an option when using the @authorization directive, but not necessarily in its current state. We believe we should add a new FILTER operation which would include authorization rules in these cases. As such, I've relabelled this as a feature request which we'll revisit once the new directive is a bit more mature.

[jroith]

@darrellwarde I see. I think this makes sense for filtering (as long as the "where" can then be disabled completely to ensure nobody can use it to peak at hidden data). For "validate" rules I'm having some doubts. To me it seems like those should produce an error in any case. But, sure, supporting this for the FILTER operation you're thinking about would also help, as long as both validate and filters are enforced correctly.

[darrellwarde]

This only makes sense in the sense of the @authentication directive because it syntactically make sense if an @authorization rule has a FILTER operation but the where tries to match against node properties. Filtering is needed to figure out whether the rule is valid against the node properties or not. Changed the title to reflect.