Skip to main content

0041: Workflow Security and Context Propagation

Date: 2025-11-08

Status: Proposed

Context​

Workflows are long-running processes, often lasting hours or days. The individual "Activities" within these workflows (ADR-0040) frequently need to make authenticated API calls to other microservices (e.g., creating a resource in the iam-service).

Passing the original user's JWT as an argument to the workflow and then to each activity is not a viable solution. The token would expire long before the workflow completes, and storing it for the duration of the workflow would be a security risk.

We need a secure and standardized way to propagate the identity of the workflow's initiator (user_id, tenant_id) to the activities so they can perform authorized actions.

Decision​

We will use Temporal's built-in Context Propagation feature to pass security principals.

  1. Interceptor at the Edge: The workflow-service API will have an interceptor. When a request to start a workflow is received, this interceptor will extract the user_id and tenant_id from the caller's JWT.

  2. Inject into Context: These principals will be injected into the Temporal Context before the workflow is started.

  3. Automatic Propagation: Temporal will automatically and reliably propagate this context to all child workflows and activities spawned by the parent workflow.

  4. Activity-Level Authentication: When an Activity needs to call another service, it will not use the original user's token. Instead, it will use a standard, trusted Service-to-Service (S2S) authentication mechanism. It will, however, pass the propagated user_id and tenant_id from its context as headers (e.g., X-Forwarded-User, X-Forwarded-Tenant).

Consequences​

Positive​

  • Security: The original user's JWT is not stored or passed around. Activities use short-lived, secure S2S tokens for authentication.
  • Decoupling & Simplicity: Developers writing activities do not need to manually handle token propagation. They simply read the user/tenant ID from the execution context provided by the Temporal SDK.
  • Auditability: Downstream services can trust the S2S token from the workflow-service and use the forwarded headers to know on whose behalf an action is being performed, which is critical for auditing.
  • Testability: Activities can be easily unit-tested by providing a mock context with the required user and tenant IDs.

Negative​

  • Initial Setup: Requires a one-time implementation of the Temporal context propagation interceptor in the workflow-service.
  • Downstream Service Trust: Downstream services must be configured to trust S2S tokens from the workflow-service and correctly handle the forwarded identity headers. This is a standard pattern in our microservices architecture.