feat(graphql-auth-transformer): @auth allow more granular access rights for read

[lazpavel]

Description of changes

• allows use of @auth directive with get/list/search/sync/listen only access rights

Customers can specify get and list operations in authorization rules.

• If customer specifies “get” operations, customers will be allowed to access get query for an item
• If customer specifies “list” operations, customers will be allowed to access scan for a list of items
• If customer specifies “search” operations, customers will be allowed to search items
• If customer specifies “sync” operations, customers will be allowed to access sync items
• If customer specifies “listen” operations, customers will be allowed to access subscribe to item events
• If customer specifies all “get” , “list”, "search", "listen", "sync", then the behavior is exactly the same as if the customer specified “read”
• If customer specifies “get” , “list”, "search", "listen", "sync" in addition to “read” in one operations array, then an error in thrown for the customer.
  “{offending operation}” operation is specified in addition to “read”. Either remove “read” to limit access only to “{offending operation}” or only keep “read” to grant both “get” and “list” access.
• When customers print out the access control matrix, it now splits out “get” , “list”, "search", "listen", "sync" operations.
• additional formatting changes to pass lint checker

Issue #9240

Description of how you validated changes

• manual testing
• yarn test passes
• additional tests added

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• New AWS SDK calls or CloudFormation actions have been added to relevant test and service IAM policies

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[alharris-at]

Couple minor comments, but overall LGTM

[Voyager-Two]

Hi,
Is this ready to be used?

Expected type ModelOperation, found get.

[lazpavel]

Hi @Voyager-Two, thank you for reporting this, we're currently investigating it

[Voyager-Two]

@lazpavel I believe I need to add this custom directive and change read to get, but not sure where to add the directive. Adding to schema.graphql gives duplicate type error.

[lazpavel]

Hi @Voyager-Two, the issue is that even the amplify-category-api latest release contains the changes, amplify-cli it's publishing a bundled package that wasn't yet referencing the latest changes in amplify-category-api, next CLI release should fix the issue. In the meantime you could try testing this by installing cli-internal package, npm i -g @aws-amplify/cli-internal or latest beta npm i -g @aws-amplify/cli@beta

[Voyager-Two]

@lazpavel

Thank you! This works great w/ latest CLI version.
And thanks to the team for making this update.

Maybe this part of the directive definition in documentation should list get list etc instead of read

Personally, I think usage of read should be discouraged, and maybe even deprecated.
It some scenarios, it can result in a security vulnerability.

For example: A model is accessible w/ API Key for guest users (no account yet). However, you only want guest users to be able to retrieve the data they created, with unique id / get. But with read, you might not realize that all guest users can technically fetch all other user data by running a manual list query.

A more specific example: Think of how public Discord invites operate; they can be sent to users that don't have accounts yet. If Discord used read, I would be able to fetch all Discord invites ever created w/ list.