[rkoster]

Summary

Add opt-in, user-facing acceptance coverage for the service-account RFC in
cloudfoundry/community#1645.

The scenarios exercise the native CF CLI and deployed CAPI, Diego, UAA and
GoRouter together. Existing test selections remain unchanged by default.

Cross-org synthetic WIF (2 scenarios)

• Create two disposable orgs: only the workload org receives a service-account
  prefix. The other org hosts a synthetic STS/protected resource without an account.
• Supply the exact CAPI-returned qualified account subject in the STS app's push
  environment, alongside explicit issuer/JWKS/audience trust.
• Two apps sharing the account obtain real UAA assertions, exchange them for an
  independently signed, in-memory STS credential and access the protected resource.
• Deny wrong-account/default-CAPI-audience assertions and unlisted resources;
  reject UAA assertions directly at the resource and exchanged credentials at CAPI.
• Disable blocks fresh assertions; enable restores the full flow.

Bearer/runtime and representative management (6 scenarios)

• Verify bearer profile, attribution and lifetime bounds through HTTPS CAPI without
  a client certificate; explicit space roles govern both shared-account callers.
• Separately cover assignment/restart semantics, desired task identity and actual
  staging exclusion using a disposable identity-observer buildpack.
• Exercise account creation/assignment/disable/enable as a regular Space Developer.
• Delete the last entitled space, discover the retained account as an Org Manager,
  entitle a replacement space and launch the same account identity again.

Identity-aware routing (3 account scenarios)

Extend the existing identity-aware routing group with qualified account sources:
shared-account access across spaces, wrong/unbound/spoofed-XFCC denial, missing
certificate rejection, policy removal, certificate-only continuity after disable
and space-domain restrictions. Existing proxy cases can use the configured egress
ASGs on restricted test foundations.

Fixtures and configuration

• Small Go workload/STS fixture with RS256 signature verification, explicitly
  configured trust, in-memory signing key, bounded responses and verified TLS.
• JWTs/private keys stay inside the app flow. CATs receives selected public identity,
  status and authorization results; no raw bearer assertions or exchanged tokens.
• Independent default-off wif.enabled, wif.runtime_tests and wif.route_tests
  toggles. Route cases also require include_identity_aware_routing.
• Documented public CA roots, existing egress ASGs, trusted issuer/JWKS/resource
  configuration and custom CLI requirements; no global UAA policy mutation by CATs.
• Normal teardown removes apps/routes/domains/buildpacks/orgs/accounts. Prefix and
  deleted-name reservations intentionally remain, as required by the RFC.

Verification

Tested against the integrated lab using source CLI b489efd50 built with its normal
version linker metadata and GOTOOLCHAIN=go1.27.3:

• 2 synthetic WIF scenarios pass with two randomized workers.
• Full identity-aware routing group passes before the focused split: 6 scenarios
  (2 account + 4 existing). After splitting disable into its own case, all 3 account
  routing cases pass together with the 6 runtime/management cases: 9 passed,
  two randomized workers.
• GOTOOLCHAIN=go1.27.3 bash ./bin/run_units: 10 existing unit suites plus fixture
  race tests pass.
• Focused go vet, gofmt, script ShellCheck and diff checks pass.
• API inventory confirms no remaining owned orgs, accounts, apps, buildpacks, routes
  or domains after the runs. Failed-setup cleanup was also exercised.

Lab component pins: CAPI/routing 0.0.0+dev.20261110100000, Diego
0.0.0+dev.20261109170000, UAA 0.0.0+dev.20261110112000 (UAA #4137 at
41d2b4a5c). Setup failures (source CLI version metadata, ASG connectivity,
buildpack archive layout and a route/domain fixture-name collision) were corrected.
Intermittent UAA connection refusal was recorded; subsequent parallel runs passed.

Helper/fixture behavior was developed in separate committed RED/GREEN slices.
Acceptance scenarios that passed against the already implemented platform are
recorded as already-green regression coverage; setup failures are not product RED.

Draft status / dependencies / limits

This depends on unreleased service-account support:

• CAPI: Implement org-owned service accounts with space entitlements and workload identity cloud_controller_ng#5520
• CAPI release: Draft: wire service-account provisioning and runtime gates capi-release#702
• BBS: Draft: add typed service-account certificate identity contract bbs#168
• Diego: Draft: propagate and issue service-account certificate identities diego-release#1216
• Routing: Add qualified service account route sources routing-release#603
• CLI: Draft: add native space-owned service-account commands cli#3875 (lab used additional local
  RFC-alignment commits through b489efd50)
• Named-resource UAA support: Feature proposal - issue #4125 uaa#4137

Supported release/CLI minimum versions need assigning as those changes land.
The synthetic STS documents a federation contract, not AWS/GCP/Azure compatibility
or full RFC8693 support; azp is informational in this fixture. JWKS loads at STS
startup. Long-running renewal, CA/JWKS rotation, near-expiry leaf-cap edge cases,
retained token behavior after disable, Windows and trusted external proxy SAN
forwarding remain separate integration work. Fixture controls have fixed operations
and destinations but no per-test authentication. A representative broker context
journey remains follow-up; exhaustive API permission/quota/reuse matrices belong
in component suites.