Implement permission policies in the API

[rijkvanzanten]

Scope

What's changed:

• Implements policy-system based permissions handling on the API
• Replaces AuthorizationService with new set of functions in the api/src/permissions folder
• Allows roles to be nested
• Adds new roles flag to accountability object. This is an ordered array of all the parent roles of the current user
• Cleans up get-ast-from-query by splitting it into multiple files
• Permissions are now injected into the AST through cases and whenCase. This allows us to dynamically generate the case/when SQL to have dynamic field output per item.
• Cleans up run-ast by splitting it up into smaller files

Potential Risks / Drawbacks

• The risks are very high. This replaces the full permissions system, and thus needs a lot of testing

Review Notes / Questions

• This PR now compiles, but doesn't run yet.
• There was some weird logic happening in the users controller for TFA enable/disable that I'm not sure we need to keep. Needs a bit more testing

Todos

• Add permissions processing for $CURRENT_USER etc flags
• Add permissions merging when you're accessing from a share
• Add caching to:
  • Fetching Policies
  • Fetching permissions
  • Fetching the roles tree
  • Fetching the field map
  • Fetching allowed fields
  • Fetching allowed collections
• Enable validation for admin users for wrong paths
• Figure out what we want to do with Presets
• Use whenCases in run-ast
• Use applyCases in Meta Service for permissions aware counts
• Handle admin-checks in roles and users services¹
• Add unit testing for clear method in memory/cache
• Make sure graphql gracefully handles optional fields when you have different fields for the same collection in multiple permission sets
• Add changeset
• Unbork /permissions endpoint

---

Closes #21778, closes #21765, closes #22163, closes #21769, closes #21768, closes #21767, closes #21766

Footnotes

1. Eg check to make sure there's still >=1 admin left after the mutation is done ↩

[changeset-bot]

⚠️ No Changeset found

Latest commit: 830b459

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[rijkvanzanten]

@DanielBiegler @hanneskuettner It'd be great if I could get a code-review while wrapping up the last todos. Once this thing is done and runs as it should, we'll involve the whole team for a good while of QA 🙂

[DanielBiegler]

Note

TODO: We gotta update /api/src/middleware/check-ip.ts and use policies there.

Previously we got the ip_access of that users role and compared it with their IP. Done.

Now users could have multiple policies which each have an ip_access column.

[rijkvanzanten]

@DanielBiegler Policies are filtered down by IP in the fetch-policies function, so every time you load in the policies set for the current accountability it'll be filtered by IP 🙂

It's no longer a yes-or-no check in middleware; it's now filtering down the permissions for the specific request.

done! :)