Integrate REVOKE permission tests into engine test suite

[tmetzke]

Acceptance Criteria (Required on creation)

• Tests ensuring the REVOKE permission mechanism works as expected are integrated into the regular engine test suite.
• Additional CI stages for REVOKE permission tests are removed (will be tested with ASSEMBLY and db-unit stages).
• The test coverage for REVOKE permissions is not decreased (can optionally be improved, if achievable with reasonable effort).

Hints

• Reasonings for the CI adjustment can be found in our Assessment Sheet (🔒internal)

Links

Breakdown

• [x] https://github.com/camunda/camunda-bpm-platform/pull/3469
  • Min. one REVOKE test for query interfaces in engine and web apps CE
  • Min. one RVOKE test for select API in engine
  • Revoke modes ALWAYS & AUTO for query authorization test in engine and web apps CE
  • Remove REVOKE stages from CE CI
• [x] https://github.com/camunda/camunda-bpm-platform-ee/pull/817
  • Ensure revoke modes ALWAYS and AUTO are tested for query interfaces using authorization checks in web apps EE.
  • Remove REVOKE stages from EE CI.

[tmetzke]

Status quo

• With the REVOKE stages, we run all engine and web app unit tests with revoke always enabled.
• All SQL queries containing authorization checks now include REVOKE checks as well, making the queries more complex.
• We ensure that all queries we test in our test suite also work as expected with REVOKE checks included, no matter if REVOKES are actually defined in the authorization table.
• Using REVOKE ALWAYS is discouraged officially due to potential performance degradation. It is a backward-compatibility option since 7.6 (was the default behavior in ≤7.5).
• Default REVOKE mode is AUTO which includes REVOKE checks only if REVOKES are defined for the user or any of its groups. This functionality is tested by the regular unit tests.
• Most query interfaces use the revoke checks in the SQL scripts (if enabled). The following query interfaces do NOT use them:
  • CaseDefinitionQuery (only tenant)
  • CaseExecutionQuery (only tenant)
  • CaseInstanceQuery (only tenant)
  • CleanableHistoricBatchReport (separate resource auth query)
  • CleanableHistoricCaseInstanceReport (only tenant)
  • HistoricActivityStatisticsQuery (separate resource auth query)
  • HistoricCaseActivityInstanceQuery (only tenant)
  • HistoricCaseActivityStatisticsQuery (only tenant)
  • HistoricCaseInstanceQuery (only tenant)
  • HistoricDecisionInstanceStatisticsQuery (separate auth check for DecisionRequirementsDefinition)
  • SchemaLogQuery (separate camunda admin permission check)
• Most APIs either use no authorization checks or the general AuthorizationManager#checkAuthorization that executes the isUserAuthorizedForResource mapping (same query for every API). The following APIs/commands use specific revoke-including queries:
  • Conditional start event (specific revoke test exists already)
  • Fetch and Lock External Task (needs a revoke test in FetchExternalTaskAuthorizationTest)

Goals

• Every Query interface using authorization check is covered by at least one test using REVOKE.
• Select additional API that uses authorization check is covered by at least one test using REVOKE.
• We ensure that revoke mode ALWAYS leads to revoke checks being present in the resulting query (can be any query interface). Since modes AUTO and ALWAYS lead to the same query behavior given AUTO evaluates to enabled, all queries and API tested above will work as expected as well.
  • Alternative: we run all authorization tests in mode ALWAYS as well

Action items

• Ensure at least one REVOKE test for the query interfaces using authorization checks.

  * [x] ActivityStatisticsQuery (added to `ActivityStatisticsAuthorizationTest`) * [x] AuthorizationQuery (added to `AuthorizationQueryAuthorizationsTest`) * [x] BatchQuery (added to `BatchQueryAuthorizationTest`) * [x] BatchStatisticsQuery (added to `BatchStatisticsQueryAuthorizationTest`) * [x] CleanableHistoricDecisionInstanceReport (added to `HistoricDecisionInstanceAuthorizationTest`) * [x] CleanableHistoricProcessInstanceReport (added to `HistoricProcessInstanceAuthorizationTest`) * [x] DecisionDefinitionQuery (added to `DecisionDefinitionAuthorizationTest`) * [x] DecisionRequirementsDefinitionQuery (added to `DecisionRequirementsDefinitionQueryAuthorizationTest`) * [x] DeploymentQuery (added to `DeploymentAuthorizationTest`) * [x] DeploymentStatisticsQuery (added to `DeploymentStatisticsAuthorizationTest`) * [x] EventSubscriptionQuery (added to `EventSubscriptionAuthorizationTest`) * [x] ExecutionQuery (added to `ExecutionAuthorizationTest`) * [x] ExternalTaskQuery (added to `ExternalTaskQueryAuthorizationTest`) * [x] FilterQuery (added to `FilterAuthorizationsTest`) * [x] GroupQuery (exists in `IdentityServiceAuthorizationsTest`) * [x] HistoricActivityInstanceQuery (added to `HistoricActivityInstanceAuthorizationTest`) * [x] HistoricBatchQuery (added to `HistoricBatchQueryAuthorizationTest`) * [x] HistoricDecisionInstanceQuery (added to `HistoricDecisionInstanceAuthorizationTest`) * [x] HistoricDetailQuery (added to `HistoricDetailAuthorizationTest`) * [x] HistoricExternalTaskLogQuery (added to `HistoricExternalTaskLogAuthorizationTest`) * [x] HistoricIdentityLinkLogQuery (added to `HistoricIdentityLinkLogAuthorizationTest`) * [x] HistoricIncidentQuery (added to `HistoricIncidentAuthorizationTest`) * [x] HistoricJobLogQuery (added to `HistoricJobLogAuthorizationTest`) * [x] HistoricProcessInstanceQuery (added to `HistoricProcessInstanceAuthorizationTest`) * [x] HistoricTaskInstanceQuery (added to `HistoricTaskInstanceAuthorizationTest`) * [x] HistoricVariableInstanceQuery (added to `HistoricVariableInstanceAuthorizationTest`) * [x] IncidentQuery (added to `IncidentAuthorizationTest`) * [x] JobDefinitionQuery (added to `JobDefinitionAuthorizationTest`) * [x] JobQuery (added to `JobAuthorizationTest`) * [x] ProcessDefinitionQuery (exists in `ProcessDefinitionAuthorizationTest`) * [x] ProcessDefinitionStatisticsQuery (exists in `ProcessDefinitionStatisticsAuthorizationTest`) * [x] ProcessInstanceQuery (added to `ProcessInstanceAuthorizationTest`) * [x] TaskQuery (added to `TaskAuthorizationTest`) * [x] TenantQuery (exists in `IdentityServiceAuthorizationsTest`) * [x] UserOperationLogQuery (exists in `UserOperationLogAuthorizationTest`) * [x] UserQuery (exists in `IdentityServiceAuthorizationsTest`) * [x] VariableInstanceQuery (added to `VariableInstanceAuthorizationTest`)
• Ensure select API is covered by at least one REVOKE test.

  * [x] Conditional start event (exists in `ConditionStartEventAuthorizationTest`) * [x] Fetch and Lock External Task (added to `FetchExternalTaskAuthorizationTest`)
• Create a test case ensuring REVOKE checks are part of a query when mode ALWAYS is chosen.
  • Alternative: run all authorization tests in both modes using parameterized JUnit tests.

[tmetzke]

Finding

• All entities using authCheckJoin remove permission for all instances of a resource type when using REVOKE for a specific instance of that resource by ID. For example, having two batch instances batch1 and batch2, granting READ permission for all batches to all users in general (using *), revoking READ access for batch1 for a specific user user1, that user cannot read any batches anymore.
• As far as I tested this, this fails for almost all entities/queries. One exception I found so far: querying for ExternalTask works as I would expect it to (note: fetchAndLock also fails with the mentioned issue).
• Notes:
  • I only tested this in unit tests so far, no manual test with a running application yet.
  • I haven't tested all potential entities yet.
  • This is out of the scope of this ticket here. If we want to follow up on this, we'll do so in a separate ticket.
  • This behavior seems to have been around for years and I cannot find any related support or community issue.