[TASK] Entra/OIDC CI scenario collapses every component audience to one app registration

[eamonnmoloney]

Description

The Entra/OIDC integration test scenario points every Camunda component at a single Entra app registration, using the same value for clientId, audience, clientApiAudience and publicApiAudience throughout.

charts/camunda-platform-8.10/test/integration/scenarios/chart-full-setup/values/identity/oidc.yaml:

orchestration:
  clientId: $ENTRA_APP_CLIENT_ID      # L32
  audience: $ENTRA_APP_CLIENT_ID      # L33
identity:
  clientId: $ENTRA_APP_CLIENT_ID      # L41
  audience: $ENTRA_APP_CLIENT_ID      # L42
optimize:
  clientId: $ENTRA_APP_CLIENT_ID      # L48
  audience: $ENTRA_APP_CLIENT_ID      # L49
connectors:
  clientId: $ENTRA_APP_CLIENT_ID      # L55
  audience: $ENTRA_APP_CLIENT_ID      # L56
  clientApiAudience: $ENTRA_APP_CLIENT_ID   # L57
webModeler:
  clientId: $ENTRA_APP_CLIENT_ID      # L63
  audience: $ENTRA_APP_CLIENT_ID      # L64
  clientApiAudience: $ENTRA_APP_CLIENT_ID   # L65
  publicApiAudience: $ENTRA_APP_CLIENT_ID   # L66

This diverges from our own documented guidance and makes the scenario blind to an entire class of audience-scoping regression.

Expected vs Actual Behavior

Expected — per microsoft-entra.md, each component gets its own app registration:

<oc-app-id>  <mgmt-identity-app-id>  <optimize-app-id>
<web-modeler-ui-app-id>  <web-modeler-api-app-id>  <console-app-id>

Actual — one app registration for everything. Rendering Optimize under this scenario collapses all three accepted audiences to the same value:

# helm template ... -s templates/optimize/configmap.yaml
audiences:
  - "11111111-2222-3333-4444-555555555555"   # clientId
  - "11111111-2222-3333-4444-555555555555"   # audience
  - "11111111-2222-3333-4444-555555555555"   # camundaHub/webModeler clientApiAudience

Two Optimize releases rendered under this scenario produce byte-identical audience lists, so any token valid for one is valid for all.

Motivation / Use Case

Three concrete problems:

1. The scenario cannot detect audience-scoping regressions. Because every audience is the same string, a change that broadens or shares an audience across components or instances is invisible — the test passes either way.

2. It diverges from documented guidance, so CI is not exercising the configuration we tell customers to deploy. A bug reachable only under the documented per-component layout would not be caught.

3. It sets a poor reference example. The scenario values are the most concrete Entra example in the repo, and customers do copy CI scenario values. Under this layout there is no audience-based isolation between any two Camunda components.

Relevant context: the audience list is currently the only isolation boundary between multiple Optimize instances (multi-OC, or Physical Tenants with one Optimize each). On Entra this matters more than on Keycloak, because iss is scoped to the tenant (https://login.microsoftonline.com/<tenant-id>/v2.0) rather than to a realm — so there is no issuer-level fallback and the audience is the only control. A CI scenario that collapses all audiences cannot protect that boundary.

Acceptance Criteria

• oidc.yaml uses a distinct audience per component, matching the app registrations documented in microsoft-entra.md (<oc-app-id>, <mgmt-identity-app-id>, <optimize-app-id>, <web-modeler-ui-app-id>, <web-modeler-api-app-id>)
• Corresponding Entra app registrations exist (or are provisioned via deploy-camunda entra) and the required CI variables are documented
• Applied consistently across affected chart versions — the same collapse exists in 8.7, 8.8, 8.9 and 8.10
• A post-deploy assertion verifies no two components share an accepted audience, so the scenario fails if they are collapsed again
• Consider extending the same assertion to the multi-Optimize scenarios (multinamespace-optimize, physicaltenants) so per-instance audience uniqueness is enforced, not just per-component

Additional Context

Occurrences of $ENTRA_APP_CLIENT_ID in each version's oidc.yaml:

Chart version	Occurrences
8.7	23
8.8	22
8.9	22
8.10	25

Note this is a test-infrastructure issue. It does not by itself change product behaviour — but it removes the test coverage that would catch audience-scoping defects, on the provider where the audience is the only available control.

References

• charts/camunda-platform-*/test/integration/scenarios/chart-full-setup/values/identity/oidc.yaml
• Docs (documents the intended per-component layout): docs/self-managed/deployment/helm/configure/authentication-and-authorization/microsoft-entra.md
• Related audience-rendering code: charts/camunda-platform-8.10/templates/optimize/configmap.yaml L36-39, templates/orchestration/files/_application.yaml L195-201
• Existing per-component audience precedent: orchestration.security.authentication.oidc.backwardsCompatibleAudiences

Environment

• Platform: GKE (distro-ci)
• Helm CLI version: 4.3.0
• Chart version: 15.0.0-alpha5 (8.10), also affects 8.7–8.9
• Kubernetes version: GKE distro-ci

[distro-ci]

🧭 Triage Assessment

Field	Value
Work type	TASK
Kind	internal
Severity	🔴 High
Likelihood	🔥 High
Confidence	0.91

📝 Rationale

Within SM Platform scope: the ownership model includes camunda/camunda-platform-helm, and prior triage precedent assigns Helm automated scenario testing and deployments to Distribution. This is a TASK, not a BUG: the current product behavior is not reported as broken; the issue requests correcting CI fixtures, provisioning distinct Entra registrations, and adding regression assertions. The Distro guidance reserves bugs for incorrect existing behavior, while CI coverage improvements are treated as internal tasks. The repository fixture currently assigns the same ENTRA_APP_CLIENT_ID to orchestration, Identity, Optimize, Connectors, and Web Modeler audience-related fields. The Entra documentation instead requires component-specific registrations and distinct values such as the orchestration, Management Identity, Optimize, Web Modeler UI, Web Modeler API, and Console applications. Kind internal is more appropriate than chore because the primary deliverable is internal CI and test-infrastructure coverage, not a customer-facing runtime capability. This matches the precedent for adding CI coverage for a documented deployment pattern. Severity is high for task triage because the gap spans multiple components and maintained chart versions, and it can allow security-relevant audience-isolation regressions to pass CI undetected. The task guidelines define high impact as cross-component technical impact or customer-impacting improvement. Likelihood is high because the collapse is deterministic in the Entra scenario, so every relevant run exercises the non-isolated configuration; related triage precedent also treats persistent CI coverage gaps as high-likelihood work. The issue contains sufficient information for triage: affected files and versions, expected and actual behavior, environment, rationale, concrete acceptance criteria, and provisioning requirements. Similar issues include the original Entra CI setup using one app registration (#3845), broader 8.10 test and documentation coverage gaps (#6308), dormant assertion coverage across maintained chart versions (#6742), multi-namespace CI coverage (#4915), and continuous multi-Optimize integration coverage (#6762).

🔍 Similar Issues

#3845, #4915, #6308, #6742, #6762

---

🤖 This issue was automatically triaged by an AI-based system.
✋ If you believe this assessment is incorrect, update the labels or add the triage:manual label for human review.