implement metadata access control through arranger integration

[hlminh2000]

• Updates to platform-api: integrate with new Arranger feature to apply default SQON on every request (awaiting feature development).
• update the arranger metadata to know about the new field
• enable with a feature flag so it can be disabled in production until ready

Detailed Description

This is to support this spec: https://wiki.oicr.on.ca/display/icgcargotech/File+Metadata+Access+Control

Possible Implementation

Use the updates from ego-token-utils above. Some pseudo-code (pending arranger investigation & implementation, please do a better job):

      const ownProgramFilter = {
        // filters out files in EMBARGO_OWN_PROGRAM stage from OTHER programs
        op: "and",
        content: [
          {
            op: "in",
            content: {
              field: "release_state",
              values: ["EMBARGO_OWN_PROGRAM"],
            },
          },
          {
            op: "not",
            content: [
              {
                op: "in",
                content: {
                  field: "study_id",
                  values: [...usersProgramIds],
                },
              },
            ],
          },
        ],
      };
      const userAccessLevel = getFileMetadataAccessLevel(jwt)
      const { schema: argoArrangerSchema } = (await createProjectSchema({
         getServerSideFilter: () => {
          switch (userAccessLevel) {
            case "DCC_MEMBER":
              return {
                // sees everything
                op: "not",
                content: [],
              };
            case "FULL_PROGRAM_MEMBER":
              return ownProgramFilter;
            case "ASSOCIATE_PROGRAM_MEMBER":
              return {
                op: "and",
                content: [
                  ownProgramFilter,
                  {
                    // filters out files in EMBARGO_FULL_PROGRAMS from OTHER programs
                    op: "and",
                    content: [
                      {
                        op: "not",
                        content: [
                          {
                            op: "in",
                            content: {
                              field: "study_id",
                              values: [...usersProgramIds],
                            },
                          },
                        ],
                      },
                      {
                        op: "in",
                        content: {
                          field: "release_state",
                          values: ["EMBARGO_FULL_PROGRAMS"],
                        },
                      },
                    ],
                  },
                ],
              };
            default:
              // public user, logged in or not
              return {
                op: "not",  // double negative --> positive
                content: [
                  {
                    op: "in",
                    content: {
                      field: "release_state",
                      values: ["PUBLIC"],
                    },
                  },
                ],
              };
          }
        },
      })) as { schema: GraphQLSchema };

Conceptual, this is to achieve the following access model:

Expected Outcome

As a user, I can login and see only the data that i have permission to from an API query

To test this:

• querying the api as a full member with no program access, see full/associate/queued data AND public data
• querying the api as a associate program member, see my program data AND associate/queued from other programs AND public data

[rosibaj]

@blabadi @ciaranschutte i checled with Minh, and this can go to QA

Yes! It's feature flagged so need an env update if you wanna test. It'll only work with the fake data cause real data doesn't have release stage yet

Would one of you be able to help moving this forward?

[blabadi]

created this PR: https://github.com/icgc-argo/platform-api/pull/350

[blabadi]

tests failed twice, and different tests each time, they seem flaky to me and related to the elastic search container lifecycle

[blabadi]

the PR branch test passed but the branch tests failed, so definitely inconsistent

[rosibaj]

@hlminh2000 can we get this moved to the dev enviroment? Are there any blockers here?

[rosibaj]

• Tests are not stable. They are complex and spinup an ES with fake data. Unknown why the test is failing.
• Feature is working fine.
• This is blocking the CI flow.
• this is still behind a feature flag.

[hlminh2000]

failing test has been disabled in CI, latest has been released to QA. Access control is behind feature flag, so no behavior change is expected out of this release.