R1 · Propagate customer identity to the system that owns the data

Domain	Identity and access management
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings B-01, B-02, B-03, I-06, L-05 · condition 02 · question Q02, Q20
Open questions	Takes a position on 17; depends on 12 and 23
Deliverables	D1.2 · D2.1 · D2.4

Concern

Aggregating the dashboard moved the authorization decision, and the design says it did not.

The GARB ADS states "No change to authorization for the MVP. Authorization remains enforced in existing product portals and applications." Its own authentication table then specifies both downstream hops — Dashboard → Integration API, and Integration API → BU Data APIs — with identity type service principal. Nothing about the customer travels past the first boundary.

B-01 — customer identity is dropped at the BFF boundary. The segment assessment rates this a blocker: "No customer claim crosses either hop. The BU Data APIs therefore cannot enforce per-customer authorization — they must trust that the Integration API has already scoped the request." The mechanism is visible in the ADS's own API table, in the Seg Funds contract GET /api/v1/investments?ciamId=:

Customer scope is a query parameter chosen by the caller, not an authenticated identity.

That is OWASP API1 Broken Object Level Authorization in its textbook form. The assessment also notes that the sequence diagram claims the design achieves "preservation of existing business-line security boundaries" and concludes: "It does the opposite: it relocates the boundary into a new component and does not describe how that component enforces it."

Three findings compound it. B-02 observes that once downstream enforcement is gone, the manually maintained BU Mapping table is the control — "and it is undocumented." I-06 puts the consequence plainly — "the fan-out service principal is effectively a master key to every customer's data." L-05 sizes the exposure at 1,435,783 customer logins per month, rising to 3,309,891 once mobile is onboarded.

This is not only a design concern

The experience map documents di-dashboard-services running in DEV and lists its known production gaps. Two of them are this finding, observed in a running service: the PROD path strips the x-federated-id header, and gb-core-authx token exchange is not implemented — memberId is hardcoded. The identity a downstream call carries today is not the caller's; it is a constant.

Recommendation

Carry the authenticated customer subject to the system that owns the record. The aggregation layer becomes a policy enforcement point that proves who it is acting for, rather than a trusted caller that asserts it.

Concretely, three properties, in this order:

The subject comes from the token, never from the request. A customer identifier supplied as a query parameter, path segment or header is an input the caller controls. Removing that affordance is what closes B-01; everything else is depth behind it.

Token exchange at the aggregation boundary. The dashboard exchanges the customer's CIAM token for short-lived, audience-restricted tokens, one per business unit, each carrying the customer subject and scoped to that BU's audience alone. A leaked or misused token then buys one downstream system for a few minutes rather than every customer's position indefinitely, which is the I-06 answer.

Then externalise the decision. With the subject present, per-BU authorization can move from implicit trust to an explicit policy decision. That is where the segment strategy already points — PingAuthorize as the decision point with the enforcement point in the BFF tier, and its distinction between what a customer may see and what they may act on, with the stricter threshold on the second. Treat this as the second step, not a precondition; the first two properties stand on their own and are deliverable inside the MVP's existing shape.

Two things make this cheaper than it first reads, and both are worth putting in front of the client early:

• The client's own reviewer already framed the fork. Condition 02 of the assessment requires "Either propagate customer identity to the BU Data APIs (token exchange / on-behalf-of), or document the compensating controls that make service-principal fan-out safe" — and then lists those controls. We are recommending the branch they named first, not introducing a new demand.
• The pattern already exists in the estate. The API landscape records gb-core-authx in Group Benefits as an RFC 8693 token-exchange service. The recommendation is to make an existing Manulife pattern the standard for the aggregation surface — not to adopt a new one. The experience map shows the dashboard BFF has simply not wired it up.

What it changes

The authentication contract of every downstream call. The assessment is explicit that this is architectural change rather than redrafting, and it is the honest cost of the recommendation: each BU Data API has to accept and enforce a customer-scoped token. That is a per-BU negotiation with a per-BU delivery cost, and WS 3 has to price it as such.

What the cache is keyed on. A cache populated by service-principal fan-out is keyed on whatever the caller passed. Once the subject is authenticated, per-customer key isolation becomes derivable rather than conventional — which is most of what B-03 asks for, and part of the answer to open question 21 on classifying the cross-BU aggregate.

What the BU Mapping Service is for. It becomes a navigation signal — which tiles to render — rather than the control that decides which financial data may be disclosed. It still needs integrity controls while it is load-bearing, but it stops being the last line.

What the target state has to show. Condition 02 also requires the ARB threat assessment covering surfaces S1–S8, and Q02 asks for a fan-out walkthrough with token claims, the enforcement point and negative tests. Our identity-and-access page and its sequence diagram (WS2-A3g) are where that gets answered.

What we are not recommending

Service-principal fan-out with compensating controls. The other branch of condition 02 is viable and we are not pretending otherwise. It loses on cost shape rather than feasibility: request-scoping proof, cache-key isolation, mapping integrity and attestation, change auditing and negative-test coverage are a permanent operational obligation carried forever by whoever owns the shared runtime — and open question 14 records that nobody owns it yet. It also leaves I-06 standing.

Waiting for the PDP. Deferring identity propagation until PingAuthorize, MDM and consent land means the MVP ships the BOLA exposure and inherits it for as long as Phase 2 slips. Subject propagation does not need the PDP.

Replacing ForgeRock. The assessment's counterweight rates reusing CIAM unchanged as the correct risk decision, and we agree. This recommendation changes what the token carries downstream, not who issues it.

Dependencies and open questions

• Open question 17 is the item this answers. It stays open until Manulife rules; this page is what it rules on.
• Open question 12 — whether MVP1 scope is fixed at no centralized authorization. If it is fixed, the first two properties are still in reach and the third is not.
• Open question 23 — whether PingAuthorize is funded and staffed or aspirational. The second step depends entirely on the answer.
• The segment strategy this leans on is dated June 2026, before the ADS and both reviews, and nothing tells us it is still endorsed — open question 10.
• Per-BU commitment to accept a customer-scoped token, with dates. Tracked as a client request alongside the other dated BU dependencies in client requests.