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
  • Introduce $CURRENT_POLICIES and $CURRENT_ROLES for permissions
  • Decide if $CURRENT_POLICIES and $CURRENT_ROLES should be available in presets as well
• 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
• Invalidate cache on permission changes
  • On directus_access changes
  • On directus_roles changes
  • On directus_permissions changes
  • On directus_policies changes
• Make public access work again, by introducing a real, public role
  • Prevent public role to be used as parent, and the public role to have any parent
• Before merging this one in main, either retarget Add roles and permissions to the app #22654 to main, or merge it in here

---

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 ↩

[hanneskuettner]

When we bring this back, we need to make sure to include && this.accountability.admin !== true in the if above, otherwise all fields will be filtered out.

[hanneskuettner]

When we bring this back, we need to make sure to include && this.accountability.admin !== true in the if above, otherwise all fields will be filtered out.

[hanneskuettner]

Anyone have a better name for this? Since in the future it might not only be flags. Should it follow the naming of the libs and maybe be called /me/global? The idea behind this endpoint is to accumulate any properties that are derived when taking all policies of a user into account, like global access and currently the enfore_tfa flag.

[DanielBiegler]

Mhh agreed /me/globals sounds better than flags to me too.

The idea behind this endpoint is to accumulate any properties

Mhh so maybe /me/properties ? 😄

If we dont expand on it /me/access sounds pretty fitting for right now, but yeah that might become less good in the future.

[hanneskuettner]

Even though this, and the other errors are really helpful, they do expose that the collection + field exists, as it differs from the standard ForbiddenError in case of a non-existent collection.