R5.2 · Fix one CIAM SSO and one token contract as the identity stack

Theme	R5 · Technology stack
Domain	Identity and access management
Status	Proposed
Needs client validation	Yes
Reinforces	R1.1 and R1.2 — the products those positions execute on
Anchored in	The ADS's security section · the June 2026 strategy's named components · the API Mediation proposal's mandatory JWT Exchange · the identity APIs enumerated in the API landscape
Open questions	Informs 23, 29, 33 and 41
Deliverables	D2.1 · D2.5

Concern

Authentication is settled. Everything above it is named in three vocabularies across four documents, and no document names the set.

Document	What it says the identity stack is
GARB ADS	Identity and access management "existing… No Change." CIAM authenticates; the dashboard trusts validated CIAM tokens. Authorization "No change… remains enforced in existing product portals." The BU Mapping Service supplies CIAM-ID-to-product mapping. The Integration API authenticates with a ForgeRock JWT as a service principal
June 2026 strategy	ForgeRock CIAM as identity provider, PingAuthorize (formerly Symphonic) as policy decision point with the PEP in the BFF tier, OneTrust as consent system of record — "identity and authorization deliberately stay inside a single Ping support boundary"
API Mediation proposal	JWT Exchange marked mandatory at the mediation layer, with the authorization server unnamed — ForgeRock, PingFederate, or a third thing
API landscape	What is registered and running: an OAuth/OIDC gateway (ext-cdt-cet-iam-gateway-prod), ForgeRock IDM (ext-cdt-cet-di-can-idm-prod), an RFC 8693 token-exchange service (gb-core-authx) in Group Benefits, entitlement APIs already split three ways by audience, and a v3 consent API

Four sources, no conflict that anyone has had to resolve, and therefore no decision. That is the condition in which a programme acquires a second token service — not by choosing one, but by three teams each needing exchange and none of them owning the estate's answer.

Recommendation

Fix the identity stack as one named product set, one CIAM SSO domain and one enterprise token contract, and record that boundary in the target state. Four statements, all of them selections rather than builds.

ForgeRock CIAM is the identity provider of record, and is not reopened. Every document agrees, it authenticates customers today, and the ADS states the constraint plainly. The value in writing it down is that a target-state document which is silent on the IdP reads as though the choice is open, and it is not. Its existing browser session supplies SSO when the portal launches an independently secured BU application.

One token means one contract, not one bearer-token instance. Web, mobile, the portal and BU applications use one supported OIDC/OAuth profile: trusted issuer, client registration, subject and assurance semantics, signing and encryption rules, token lifecycle, step-up and logout. Each application still receives its own client- and audience-specific tokens. Sharing the portal's bearer token across BUs would contradict the boundary the decision is meant to establish.

gb-core-authx remains the candidate enterprise exchange component when aggregation needs delegation. The launch-first MVP does not need RFC 8693 because the customer enters the BU application and that application runs its own OIDC flow. If a later portal release calls BU APIs on the customer's behalf, the mediation proposal's mandatory exchange capability becomes the standard rather than a per-domain build.

PingAuthorize is the enterprise visibility decision point, enforced by the BFF. The strategy has already selected the PDP and the UCL HLD supplies the boundary: enterprise coarse, BU fine. The mediation layer validates and exchanges the customer token; it does not replace the visibility PEP. Each BU API remains a separate resource PEP for object- and action-level authorization. Those two enforcement points are not competing because they guard different decisions.

Why this is separable from R1

R1.1 argues that independently launched BU applications use the shared CIAM SSO session under one token contract. R1.2 argues that the dashboard's enterprise visibility decision must come from PingAuthorize rather than a mapping table. Both are positions on behaviour, and both can be accepted while teams still implement incompatible OIDC profiles or token services.

This is the product set those positions run on, it has a different counterparty — the Canada Digital Identity platform and the office that authored the mediation proposal, rather than each business unit — and it is decidable earlier, because nothing about it waits on a per-BU negotiation.

What it changes

It gives the mediation proposal's identity question a candidate to rule on. The proposal asks whether the authorization server is ForgeRock, PingFederate or something else and does not answer. A named set is something the Chief Architect's office can accept or reject, which is more useful than a further question.

It converts open question 23 from a validation item into a funding one. Are PingAuthorize, OneTrust and the operational profile funded and staffed, or aspirational? If the answer is no, this recommendation does not change — it becomes the funding case, and the target state records a selected PDP with an unfunded date rather than an unselected PDP.

It sets the boundary open question 33 resolves against. The three audience-split entitlement APIs already in PROD are either inside this stack or adjacent to it, and R1.2 rests on the answer.

What we are not recommending

Replacing ForgeRock. The ADS calls it a fixed constraint and we agree.

Procuring anything. The products and capabilities are already named in client material or registered in the estate. The recommendation is selection and boundary-drawing, and its cost is a decision, not a licence.

Migrating Group Benefits' existing gb-core-authx consumers. What GB already does continues. Enterprise promotion is triggered only when a portal release needs delegated API aggregation.

Specifying token lifetimes, claim sets or audiences. SOW Schedule "A" §3.0 puts implementation design out of scope. This recommendation fixes the common OIDC/OAuth contract and trust boundary, not the values inside each client registration or token.

Dependencies and open questions

• Open question 29 — whether the mediation proposal is live, endorsed and funded. If it is superseded, the JWT Exchange mandate loses its force and the later delegated-aggregation path needs another enterprise owner; the launch-first SSO decision is unchanged.
• Open question 23 — PingAuthorize and OneTrust funding.
• Open question 33 — what the registered entitlement APIs decide, and their relationship to the unexpanded UES in the ADS's Phase 3 scope.
• A named owner for gb-core-authx at enterprise scope. It is a Group Benefits service today, and Group Benefits did not sign up to run the estate's exchange.