Historic Task Autorizations

Requirement

Make it possible to configure authorizations in a way that a user is able to see (READ) details about tasks (including submitted variables) for tasks they have worked on themselves from history.

More precisely: make it possible to configure authorizations in a way that a user can see all tasks they have worked on (they have been assiged to), including data (variables) that have been submitten when completing the task, without seeing tasks they have not worked on.

Context

For the camunda Runtime API, it is possible to define fine-granular authorization checks on a resource level (Tasks vs. Process instances ...) and permission level (read, ...)

In History, the possibility to authorize access is more coarse-grained: it is possible to define READ_HISTORY permissions on a process definition level.

AT

• Introduce new historic task resource with the following permissions:
  • Read
  • Read Variable
• When an identity link is added to an active task, an authorization is added to the historic task resource with read permission on the task id
• When the task gets completed, only the runtime authorization is removed but not the authorization on the historic task resource
• When enforceSpecificVariablePermission is configured to true and an identity link is added to an active task, additionally to the read permission also the read variable permission is added to the historic task resource on the task id
• The historic task authorizations are enforced for the following queries
  • Historic Task
  • Historic Variable
  • Historic Detail
  • Identity Link Log
• History Cleanup
  • The removal time and root process instance id columns are added to the authorization table
  • When an identity link is added, the root process instance id and if already present the removal time is set to the authorization related to the historic task resource
  • When an user creates an authorization on the historic task resource and enters a resource id of an existing task, the root process instance id and if already present the removal time is set to the authorization
  • The batch operation "Set Removal Time for Processes" takes historic task authorizations into account
  • The cleanup execution takes historic task authorizations into account
  • The legacy history cleanup mechanism (end time based) does not take historic task instance authorizations into account
• A config flag enableHistoricInstancePermissions is in place
  • The default value is false to avoid performance degradation for queries and don't show more information to the user than before
  • When disabled, ...
    • historic task authorizations are not created when adding an identity link
    • when a user proactively creates a historic task authorization, the root process instance id/removal time is added if available
    • the extra SQL for queries is skipped
• Root process instance id and removal time is exposed to the REST API
• Historic task instance authorization is removed when deleting a historic task via API
• In Admin, I can grant the newly introduced authorizations
• I can read docs