security: add authorization checks to WorkflowHttpHandler

[adilburaksen]

The workflow run endpoints under /v3/namespaces/{namespace-id}/apps/{app-id}/workflows/{workflow-id}/runs/{run-id} accessed workflow run data and workflow run state using only the namespace, application and workflow names from the request path, without enforcing any access control on the selected workflow program.

This change injects ContextAccessEnforcer into the handler and enforces access on the workflow ProgramReference before each operation:

• Read endpoints (workflow token, node-level token, node states, local datasets) enforce StandardPermission.GET.
• State-changing endpoints (suspend, resume, delete local datasets) enforce StandardPermission.UPDATE.

This mirrors the program-level enforcement already performed by the sibling program runtime handler and the other authorization PRs in this area. Hardening only; no functional change for authorized callers.

[gemini-code-assist]

Code Review

This pull request integrates authorization checks into WorkflowHttpHandler by injecting ContextAccessEnforcer and enforcing permissions (UPDATE or GET) across various workflow endpoints. However, a critical compilation issue was identified: the contextAccessEnforcer.enforce method throws a checked exception (AccessException), but enforceWorkflowAccess and several calling endpoints do not declare or handle this exception, which will prevent the code from compiling.

[gemini-code-assist]

The contextAccessEnforcer.enforce method throws AccessException, which is a checked exception. However, enforceWorkflowAccess does not declare throws AccessException (or throws Exception) or catch it, which will cause a compilation error.

To resolve this, enforceWorkflowAccess should be updated to declare throws Exception (or throws AccessException). Additionally, all calling endpoint methods that do not already declare throws Exception (such as getWorkflowToken, getWorkflowNodeStates, getWorkflowLocalDatasets, and deleteWorkflowLocalDatasets) must also be updated to declare throws Exception in their method signatures to propagate the exception correctly.

Suggested change

	private void enforceWorkflowAccess(String namespaceId, String appId, String workflowId,
	StandardPermission permission) {
	ProgramReference programReference = Ids.namespace(namespaceId).appReference(appId)
	.program(ProgramType.WORKFLOW, workflowId);
	contextAccessEnforcer.enforce(programReference, permission);
	}
	private void enforceWorkflowAccess(String namespaceId, String appId, String workflowId,
	StandardPermission permission) throws Exception {
	ProgramReference programReference = Ids.namespace(namespaceId).appReference(appId)
	.program(ProgramType.WORKFLOW, workflowId);
	contextAccessEnforcer.enforce(programReference, permission);
	}

[adilburaksen]

@sahusanket @vsethi09 — would one of you be able to take a look at this small security cluster when you have a moment?

These four PRs add per-resource authorization to external /v3 handlers that currently invoke no ContextAccessEnforcer, so any authenticated user can read or act on another namespace's resources. Each change mirrors the enforcement already present in the sibling handlers (e.g. ConnectionHandler, ProgramRuntimeHttpHandler, LineageHTTPHandler):

• security: add authorization checks to WorkflowHttpHandler #16156 — WorkflowHttpHandler (this PR): cross-namespace workflow-token secret read + suspend/resume. Runtime-confirmed against the real store + DefaultContextAccessEnforcer: the enforcer denies the test user on the victim namespace, yet the handler returns that namespace's token (incl. a db.password value) and never consults the enforcer.
• security: add authorization checks to OperationsDashboardHttpHandler #16155 — OperationsDashboardHttpHandler: cross-namespace program-run records + operator-PII read.
• security: add authorization checks to OperationHttpHandler #16157 — OperationHttpHandler: fulfills the pre-existing // TODO(CDAP-20881): Add RBAC check.
• security: add authorization checks to UsageHandler #16158 — UsageHandler: cross-namespace dataset/program topology.

All four are small (an enforceOnParent(...) before the store operation) and the gemini-code-assist review feedback has been addressed. Happy to rebase or adjust to match your preferred enforcement pattern.

[adilburaksen]

@sahusanket @bhardwaj-priyanshu — gentle follow-up on this small cross-namespace authz cluster (original ping Jun 2). This adds the missing ContextAccessEnforcer check to WorkflowHttpHandler: today a user with access only to their own namespace can read another namespace's workflow-run token. It's runtime-confirmed — in the PoC the real DefaultContextAccessEnforcer denies the test user on the victim namespace, yet the handler returns its secret (db.password) and never calls the enforcer (Mockito verifyNoInteractions). Sibling ProgramRuntimeHttpHandler already enforces, so this is a gap, not by-design. Companion fixes mirror the same pattern: #16155 (OperationsDashboard), #16157 (OperationHandler), #16158 (UsageHandler). All green/CLA-signed. Could one of you take a look when you have a moment? Thanks!