R1.1 · Launch BU applications through one CIAM SSO

Theme	R1 · Identity and authorization
Domain	Identity and access management
Status	Proposed
Needs client validation	Yes
Anchored in	The ADS's OIDC Authorization Code + PKCE contract and existing SSO-federation hop · the UCL HLD's universal authentication, SSO and session-management capability · assessment finding B-01 as the boundary this launch-first scope must not cross
Open questions	Constrains 17; depends on 12 and 34
Deliverables	D1.2 · D2.1 · D2.4 · D2.5

Concern

Aggregating the dashboard moved the authorization decision out of the product portals and into a new component, and the design says it did not.

The GARB ADS says it twice, on facing pages. Page 10: "For MVP, authorization remains within individual product portals." Page 11: "No change to authorization for the MVP. Authorization remains enforced in existing product portals and applications. Access follows least-privilege principles so customers see only their products and data."

Its own authentication table, on those same two pages, is where the claim comes apart. It gives four hops. Customer → CIAM carries Customer Identity, and Unified Dashboard → Product Portals carries Authenticated Customer Identity over the existing SSO federation. The two hops between them — Dashboard → Integration APIs, and Integration APIs → Backend Services — carry Service Principal. The customer's identity survives the route that still ends in a product portal, and is replaced on both routes the MVP builds. Nothing about the customer travels past the first boundary.

Page 10 also records a trust boundary "between the Unified Dashboard and downstream product portals/API" that did not exist before this design. A trust boundary is where a decision gets made, and the component on the near side of this one has no customer claim to make it with. What keeps "customers see only their products and data" true is no longer a product portal's authorization model — it is the BU Mapping table the dashboard reads, which is B-02 below.

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

Make the portal a trusted launch surface for MVP1, not a proxy for BU customer data. When a customer selects a product, the portal opens the independently secured BU application. That application starts its own standard OIDC Authorization Code + PKCE flow with ForgeRock CIAM; CIAM's existing session supplies SSO, normally without asking the customer to authenticate again. The BU application receives tokens issued for its own client and audience, establishes its own application session, and keeps object-, action- and transaction-level authorization inside the BU boundary.

Concretely, three properties, in this order:

One SSO session. ForgeRock CIAM remains the authentication authority. Each BU application is an OIDC client, but the customer signs in once: the app's authorization request returns to the same CIAM session and receives its own authorization code without another credential prompt when policy allows.

One token contract, not one reusable bearer token. Web, mobile, the portal and BU applications use one enterprise OIDC/OAuth profile: trusted issuer, signing and encryption rules, subject semantics, assurance context and lifecycle controls. Tokens remain client- and audience-specific. The portal never passes its access token, a customer identifier in a URL, or a caller-selected identity header to the BU application.

Navigation is the MVP security boundary. The portal may decide which product link to offer, but protected BU balances, claims and transactions remain inside the BU application. If the portal later aggregates customer data from BU APIs, this recommendation no longer closes B-01: the API path then requires RFC 8693 token exchange or the assessment's full compensating-control branch.

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

• The ADS already declares both contracts. CIAM uses OIDC Authorization Code + PKCE, and the existing dashboard-to-product-portal hop carries authenticated customer identity through SSO. This recommendation makes that working path the explicit MVP pattern.
• The estate already operates this way at scale. The segment assessment records fourteen customer-facing OIDC clients across web and mobile. The recommendation standardizes their trust contract; it does not introduce another identity provider or shared login mechanism.
• It avoids pretending navigation and aggregation are the same release. The assessment permits manual mapping for navigation and rejects it for disclosure of financial data. A launch-first MVP stays on the permitted side of that line while the enterprise visibility and relationship capabilities mature.

What it changes

The MVP is navigation-first. Product tiles may carry the metadata needed to identify and launch a BU application. They do not carry balances, claims or other protected BU data retrieved through the new service-principal fan-out. That scope boundary removes the unsafe path rather than compensating for it.

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. R1.2 can replace that visibility inference with an explicit enterprise decision without changing the BU launch contract.

What every BU application must implement. Each independently launched application needs an approved OIDC client registration, exact redirect URIs, Authorization Code + PKCE, token validation, local session controls and coordinated logout and recovery behaviour. The shared SSO session removes the second login; it does not remove the BU application's security boundary.

What the target state has to distinguish. The identity-and-access sequence must show two different journeys: front-channel OIDC SSO when the customer opens a BU application, and delegated API authorization if a future portal release aggregates BU data. One cannot be labelled as the other.

What we are not recommending

One shared bearer token. “One token” means one enterprise token contract, issuer strategy and trust model. Reusing the portal's token in every BU would erase audience boundaries and turn token leakage into cross-BU access.

An OAuth flow inside every embedded micro-frontend. A micro-frontend rendered inside the portal does not become a separate security application by naming it one. OIDC belongs to an independently launched BU application or its BFF, not to every component on one composed page.

Service-principal aggregation of protected customer data. If balances or claims remain on the portal surface, removing token exchange while keeping fan-out leaves B-01 unchanged. That release must either add customer delegation or implement and own every compensating control in condition 02.

Discarding token exchange. RFC 8693 remains the correct later pattern for server-to-server calls made on the customer's behalf. It is deferred because the launch-first path does not make those calls, not because SSO solves API delegation.

Replacing ForgeRock. The assessment's counterweight rates reusing CIAM unchanged as the correct risk decision, and we agree. This recommendation makes its existing SSO capability the explicit handoff contract.

Dependencies and open questions

• Open question 12 — whether MVP1 scope is fixed at no centralized authorization. The launch-first path fits that constraint only if protected BU data is not aggregated onto the dashboard.
• Open question 17 remains the gate for any future aggregation release. SSO answers application launch; it does not answer customer delegation to BU Data APIs.
• Open question 34 — whether a “BU sub app” is an independently launched application, a route inside the shell or an embedded runtime remote. Only the first has an unambiguous independent OIDC boundary.
• Confirmation from the identity platform that web, mobile, portal and BU clients use one supported OIDC/OAuth token contract and one CIAM SSO domain, including logout, step-up and recovery behaviour.