A custom header 'x-user-id' is used in core part

I wanted to bring to your attention an issue that was identified by our GC Team while they were in the process of addressing #157 (closed).

org.opengroup.osdu.workflow.service.WorkflowRunServiceImpl#addUserId

 private Map<String, Object> addUserId(String workflowName, TriggerWorkflowRequest request) {
    final Map<String, Object> executionContext = request.getExecutionContext();

    if (executionContext.get(KEY_USER_ID) != null) {
      String errorMessage = String.format("Request to trigger workflow with name %s failed because execution context contains reserved key 'userId'", workflowName);
      throw new AppException(400, "Failed to trigger workflow run", errorMessage);
    }
    String userId = dpsHeaders.getUserId();
    log.debug("putting user id: " + userId + " in execution context");
    executionContext.put(KEY_USER_ID, userId);
    return executionContext;
  }

The current logic relies on a custom header that is primarily intended for use at an infrastructural level, as outlined in home#52 (closed). The GC team approved an ADR with the understanding that this custom header would not be utilized within the core codebase.

However, as indicated in osdu/platform/deployment-and-operations/helm-charts-azure!366 (merged), a header named 'x-user-id' is populated with data from 'x-on-behalf-of' using a specific rule. This mechanism aligns with the requirements of the CSP provider but may not be entirely suitable for the Core Part of the Workflow Service.

 if (jwt_authn[msft_issuer]["appid"] == serviceAccountClientId and on_behalf_of_header ~= nil and on_behalf_of_header ~= '') then
                        request_handle:headers():add("x-user-id", request_handle:headers():get("x-on-behalf-of"))
                      else  
                        request_handle:headers():add("x-user-id", jwt_authn[msft_issuer]["appid"])
                      end

This logic introduces three key issues:

• The core part of the Workflow service depends on a custom CSP header to execute context, which may not be in alignment with the intended architecture.
• The Workflow service may not operate correctly without and the accompanying special rule, potentially limiting its usability.
• There is a security concern in that 'x-user-id' is not currently validated on the BackEnd side, allowing any user to utilize it for potentially vested interests.

As for the third problem, there is the test case:

1. A user was authorized within Workflow Service.
2. This user uses 'x-user-id' with the name of another user, resulting in the triggering of a workflow under the identity of a different user.