[Bug]: Aggregations does not respect column level security

[vadeveka]

What happened?

Aggregations does not respect the column level security requirements specified in DAB config.

Given books table contains columns id, title and publisher_id, consider an entity config like below.
The expectation is that aggregations should not expose publisher_id yet we see from above screenshot that it is not handled.

We should look into ways to address this gap or provide recommendation to atleast disable aggregation from DAB config (is there a switch exposed?) so that CLS on read operation is not exposed via groupBy+aggregation field

    "Books": {
      "source": {
        "object": "dbo.books",
        "type": "table",
        "key-fields": [
          "id"
        ]
      },
      "graphql": {
        "enabled": true,
        "type": {
          "singular": "Books",
          "plural": "Books"
        }
      },
      "rest": {
        "enabled": true
      },
      "permissions": [
        {
          "role": "reader1",
          "actions": [
            {
              "action": "read",
              "fields": {
                "include": ["id", "title"]
              }
            },
            {
              "action": "create"
            }
          ]
        },
        {
          "role": "rlsreader",
          "actions": [
            {
              "action": "read",
              "policy": {
                "database": "@item.id eq 123"
              }
            },
            {
              "action": "create"
            }
          ]
        }
      ]
    },

Version

1.5.56

What database are you using?

Azure SQL

What hosting model are you using?

No response

Which API approach are you accessing DAB through?

No response

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct

[vadeveka]

Per HotChococlate docs

At the core of authorization with Hot Chocolate is the @authorize directive. 
It can be applied to fields and types to denote that they require authorization.

This means we may not be able to apply authorize directive on the arguments on the aggregation operations to block the restricted field usage in a native approach. We may need explicit validation logic in the resolvers.

[JerryNixon]

Does secured data return in an insecure way?