Multiple-create: Authorization

[ayush3797]

Why make this change?

Since GraphQL insertions now support nested insertions, we need to authorize entity and fields not only for the top-level entity in the insertion, but also the nested entities and fields. This PR aims to address that logic of collecting all the unique entities and fields belonging to those entities in a data structure, and then sequentially iterate over all entities and fields to check whether the given role is authorized to perform the action (here nested insertion).

What is this change?

1. The presence of the model directive on the output type of the mutation object will be used to determine whether we are dealing with a point mutation or a nested insertion. Presence of model directive indicates we are doing a point insertion while its absence indicates the opposite. This logic is added to SqlMutationEngine.ExecuteAsync() method. This logic determines whether the input argument name is item (for point mutation) or items (for insert many).
2. A new method SqlMutationEngine.AuthorizeEntityAndFieldsForMutation() is added. The name is kept generic (instead of using 'Insertion') because the same method can be used later for nested updates as well. As the name indicates, this method iterates over all the entities and fields and does the required authorization checks.
3. The method mentioned in the point above depends on another newly added method SqlMutationEngine.PopulateMutationFieldsToAuthorize() whose job is to populate all the unique entities referred in the mutation and their corresponding fields into a data structure of the format:
   Dictionary<string, HashSet<string>> entityAndFieldsToAuthorize - where for each entry in the dictionary:
   -> Key represents the entity name
   -> Value represents the unique set of fields referenced from the entity
4. The method SqlMutationEngine.PopulateMutationFieldsToAuthorize() recursively calls itself for nested entities based on different criteria explained in code comments.
5. When the field in a nested mutation is a list of ObjectFieldNode (fieldName: fieldValue) or the field has an object value, the fields are added to the data structure mentioned in (3) using a newly added method: SqlMutationEngine.ProcessObjectFieldNodesForAuthZ() which sequentially goes over all the fields and add it to the list of fields to be authorized. Since a field might represent a relationship- and hence a nested entity, this method again calls its parent caller i.e. SqlMutationEngine.PopulateMutationFieldsToAuthorize().
6. The method SqlMutationEngine.ProcessObjectFieldNodesForAuthZ() contains the logic to ensure that the fields belonging to linking tables are not added to the list of fields to be authorized.
7. Moved the method GetRoleOfGraphQLRequest() from Cosmos/SqlMutationEngine to AuthorizationResolver.

How was this tested?

To be added.

Sample Request(s)

1. Config:
   
   

2. Request/Response - AuthZ failure because piecesAvailable field is not accessible to test_role_with_excluded_fields_on_create role.
   

3. Request/Response: Removing piecesAvailable field from request body leads to successful authz checks (request fails during query generation).

[ayush3797]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[seantleonard]

The PR description example doesn't touch on authorization of "multiple mutations." Yes, there is a relationship field in the mutation, but your example doesn't demonstrate authorization of fields/entities defined by that relationship field.

[seantleonard]

Looks good so far. I'd say only thing that this PR would benefit from is testing authz of sub-entity fields. Unless i missed it, i only saw tests for Top-level entity and fields and sub-entity (no fields)

[ayush3797]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).