Unified Portal - Architecture Recommendations Overview
| Prepared For | Manulife |
|---|---|
| Purpose | Review and ensure direction of Konrad's select recommendations for enterprise identity and entitlement model |
| Status | In Review |
| Architecture Diagram | Official link to come; select diagrams have been included alongside write-up below for now |
| Version | Version 2 - Monday, Oct 12, 2026 |
| Revision history | Version 2 reflects Manulife's ruling that Informatica MDM is the Enterprise Relationship Registry and that ECID and rel_id are one identifier (ADR-0006). It withdraws Version 1's separate-registry position. Version 1 - Friday, Sep 18, 2026 |
Understanding the Problem
Manulife is able to identify a customer once, but cannot say what that identity is worth across the entire organization. Auto-linking products across LOBs is a primary pain point because enterprise IDs have complex, interconnected entitlements. It’s unfortunate to think that customers who belong to more LOBs can have a poorer, disjointed experience.
Here is an example sequence that outlines the problem:
- A Manulife customer gets enrolled in a Group Benefits plan through their employer. GB's system enrolls and solely knows of the customer.
- The enterprise view learns nothing. No event, no feed, no integration carries that customer out of GB.
- In the event a customer arrives at the portal's product selection page, they are able to manually link their GB member ID.
- Only at this point does a row exist in the BU Mapping Service saying this Manulife ID holds a GB product, and only now can a unified dashboard render the GB tile.
From this sequence, you can understand the problem in 3 parts:
| The question at hand | |
|---|---|
| Resolution | Which products does this identity hold? |
| Decision | May this identity be shown in this product? |
| Propagation | Can the system holding the data verify either? |
Manulife can authenticate a customer consistently through ForgeRock CIAM, but the shared experience cannot yet establish three facts on an enterprise basis: which products that identity holds, which of those products may be displayed, and how a business-unit API can verify the customer on whose behalf it is being called. The result is a correctly authenticated customer entering a path whose ownership, disclosure and downstream authorization controls are not equally trustworthy.
Here is a more technical detailed illustration of the problem when factoring in the Dashboard BFF:
- A customer signs in through ForgeRock CIAM and receives a valid customer identity.
- The dashboard reads a manually populated CIAM-ID-to-product mapping to decide which products to retrieve and display.
- The dashboard BFF and Integration API call downstream services as service principals. The customer's authenticated subject does not survive both new hops.
- A BU Data API therefore receives a trusted application caller, but not proof of the customer
whose data was requested. In at least one documented contract, the customer scope is supplied as a request parameter. - A missing, stale, or incorrect mapping can hide the customer's product or request another
customer's record without the resource-owning API having enough authenticated context to detect the error.
This is the combined effect of findings B-01 and B-02 in the segment architecture assessment: customer identity is dropped at the BFF boundary, while a mapping suitable for navigation becomes the disclosure control. The GARB ADS describes both behaviours while also stating that authorization is unchanged.
Key Observations
To begin, let’s revisit our core 3 Problem Parts:
| The question at hand | Findings | |
|---|---|---|
| Resolution | Which products does this identity hold? | The customer creates links manually |
| Decision | May this identity be shown in this product? | The dashboard infers an answer from the BU mapping |
| Propagation | Can the system holding the data verify either? | The new API path arrives as a service principal |
Manulife's 2026-06-13 proposed architecture provides a strong foundation. Its separation of responsibilities is sound: experience composes, access governs, the operational profile serves, and MDM masters. It also names ForgeRock CIAM, PingAuthorize, OneTrust, an operational profile, and a governed MDM relationship graph. The distinction between what a customer may see and what they may do is particularly important. To build on it, we must observe and identify gaps or possible areas to improve on in the hypothesis.
The material does not yet align on how those components reach the target:
- The API Mediation proposal marks JWT Exchange mandatory, and the API landscape records an RFC 8693 exchange service in Group Benefits. The ADS path instead replaces the customer with a service principal.
- The UCL HLD states “enterprise coarse, BU fine,” with the enterprise deciding product visibility and the BU deciding actions. The ADS excludes centralized authorization and uses the manual mapping on the dashboard path.
- The June strategy assigns product auto-association to “MDM + BU,” while the UCL discovery question asks each BU for its earliest system-confirmed ownership signal. These are two different activities: recording an ownership fact for a known identity and resolving whether two historical identities are the same person.
- The same capability appears as a 2026 first deliverable, ADS Phase 2, and a 2027–2028 roadmap outcome. The target architecture should therefore define contracts that can be adopted incrementally rather than depend on one programme date.
Recommendation
Give resolution, decision, and propagation separate contracts. ForgeRock CIAM remains authoritative for authentication, the shared SSO session and runtime identity context; it is not the system of record for customer-product relationships. Informatica MDM, which Manulife has confirmed as the Enterprise Relationship Registry, holds accepted, verified relationship facts and their provenance alongside identity resolution. PingAuthorize governs what products the portal shows, while each BU API independently authorizes access to its own data.
We retain Manulife's selected identity products, four-layer architecture and MDM-centred authority model, but propose changes to how BU product facts reach MDM, what PingAuthorize decides, and how the customer identity reaches the resource-owning API.
Enterprise Relationship Registry
The Enterprise Relationship Registry is the role that holds accepted links between enterprise identity, business-unit identifiers and Manulife products. Manulife has ruled that Informatica MDM carries it.
For example:rel_id 123 → CIAM subject C456 → policy P789 → Insurance
MDM governs the full rel_id lifecycle (issue, link, merge, unmerge, redirect and end of relationship), CIAM and BU-specific identifier aliases, accepted product, account and policy links, and each link's status, evidence and effective dates, alongside match/merge, survivorship and lineage. It is not an authentication authority and does not serve channel reads: the D3 operational profile does, so no login calls MDM. ForgeRock IDM holds the event-fed crosswalk replica (the ECR), which never matches or mints rel_id.
Product ownership resolution — before and afterdraft — not for client viewing
The capabilities the registry consolidates were distributed across Manulife's material:
| Manulife Material File | Capabilities mentioned |
|---|---|
| GARB ADS | BU Mapping Service, ECID (the ADS's name for rel_id) mapping and auto-linking. |
| June strategy | MDM mastered relationship graph, MDM + BU product association, operational profile. |
| Target architecture draft (UC-ARCH-002) | Informatica MDM as the only matcher and only issuer of rel_id; ForgeRock IDM as the event-fed ECR. |
| MDM use-case inventory | Informatica MDM as system of record and Enterprise Relationship Registry. |
| UCL HLD | Customer identifiers, real-time BU synchronization, B2B relationship traversal and event-driven lifecycle. |
| API inventory | Existing ForgeRock IDM and BU Mapping APIs. |
Decided: MDM is the registry
On Oct 12, 2026 Manulife ruled that Informatica MDM is the Enterprise Relationship Registry (ADR-0006), closing open question 43. MDM is the source of truth for accepted customer-to-product relationships as well as for identity resolution, and it owns the rel_id lifecycle. ECID and rel_id are one identifier; this document uses rel_id, the name in Manulife's target architecture draft.
Konrad's Version 1 position, a separate registry owning the identifier lifecycle and accepted operational links with MDM limited to ambiguous and legacy resolution, is withdrawn. Two parts of it survive inside MDM. Each BU still emits the ownership event, and onboarding still splits into a deterministic provisioning link, formed by MDM's search-before-create at origination, and a back-book resolution link, formed by MDM match/merge.
The cost is that MDM sits on the first-access path. With no provisional ID, a customer has no dashboard until MDM issues or links rel_id, so match latency, stewardship backlog and MDM availability become customer-journey concerns rather than data-quality ones.
Delivery gate: Informatica product fit
The role is decided; whether Manulife's installed Informatica product, version and topology can carry it is not. Open question 51 asks whether it meets the operational profile's freshness, ordering, replay, unmerge and dual-region recovery requirements. If it falls short, the remedy has to come from MDM's own delivery (configuration, edition or topology), because a second registry is no longer an option. The PingIDM product-fit assessment proposed in R5.5 does not proceed.
To further explore the recommendation, we can now break down into 3 core areas:
- BU-authored product-relationship facts, accepted by MDM and bound to
rel_id. - PingAuthorize for enterprise visibility - BU APIs retain action authorization.
- One CIAM session with audience-bound tokens - and token exchange when protected data is aggregated.
1. Resolution - BU-authored ownership, accepted by MDM
Given the customer who signed in, which Manulife products belong to them?
Today, ForgeRock authenticates the customer.
- The customer manually enters a BU-specific account, policy, or membership identifier — sometimes through 3–12 steps.
- The BU Mapping Service stores a link such as
CIAM ID → GB membership. - The portal reads that mapping to determine which products appear.
We split the problem into two paths: new relationships, where a BU can assert its own product fact and supply binding evidence, and existing or uncertain relationships, where identity resolution is required.
- Authenticate customer — ForgeRock establishes the CIAM subject.
- Assert the product relationship — the BU identifies its local customer, account, policy or membership and the relationship it created.
- Bind it to enterprise identity —
- New: an authenticated onboarding journey supplies the CIAM subject and evidence connecting it to the BU transaction, and MDM's search-before-create forms the provisioning link at origination.
- Existing: MDM match/merge or governed manual verification resolves the BU identifier to the enterprise person.
- Accept the relationship — MDM, as the registry, verifies the evidence, issues or reuses
rel_idand records the link. - Serve the relationship — MDM publishes the change; the operational profile supplies the portal and PingAuthorize, and ForgeRock IDM's crosswalk replica is updated from the same event.
New relationships
When a BU enrolls a member, opens an account or issues a policy, it is authoritative for that product relationship and its BU-local identifiers. It does not thereby master the enterprise person identity. If creation occurs in a CIAM-authenticated journey, the BU can submit the CIAM subject together with the product transaction and the evidence that binds them.
When the relationship ends, the BU publishes the corresponding end fact using the same identifiers and evidence chain, and MDM records the accepted start or end against the customer's rel_id. Manulife's target draft designs merge and unmerge but not the end of a relationship, so the end fact needs a place in MDM's intake contract as the counterpart of the ownership event.
Until each BU emits that event, product ownership reaches MDM in batch, and a new product cannot be linked at the moment it is created.
Existing or uncertain relationships
Historical records may contain different names, identifiers or conflicting data. MDM determines whether those records represent the same person, applies match/merge, survivorship, stewardship and consent controls, and returns a verified outcome. Governed manual verification remains the exception path when automation cannot establish the binding.
The BU fact and the enterprise identity binding are separate assertions. The BU authors the former; CIAM-authenticated evidence, MDM match/merge or stewardship establishes the latter. Both paths land in MDM: they differ in how the binding is established, not in where it is recorded.
Manual linking remains temporarily for exceptions. Each BU's ownership signal, binding evidence and accountable verifier, now an intake contract into MDM, still require client confirmation under open question 42. The delivery owner for the registry role depends on who inherited the cancelled WS 1 Unified Identity MVP (open question 15).
Product ownership resolution — before and afterdraft — not for client viewing
Binding contract: BU identifier to authenticated CIAM subject
The enterprise contract must namespace the source and BU-local customer, account, policy or membership identifiers; identify the BU system authorized to assert that product domain; carry an immutable event ID, relationship state and effective dates; and include the verification method or evidence reference, provenance and audit state. For a new relationship, the evidence must bind the BU transaction to the authenticated CIAM subject; MDM then issues or reuses rel_id. A subject must not be supplied as an unverified query parameter or caller-selected header. Legacy records follow MDM's match/merge or stewardship resolution path.
The system that creates or terminates a product relationship emits the product fact. MDM validates the evidence, routes ambiguity to match/merge or stewardship, and only then publishes an accepted link for projection. The contract remains technology-neutral and does not prescribe an event payload or transport.
2. Decision - PingAuthorize for enterprise visibility, using rel_id context
The portal BFF asks an explicit policy question: “May this identity be shown this product?”
Before beginning, it’s important to note that PingAuthorize is already named in Manulife's strategy. Our thoughts turn that strategy into a clear authority model and narrow what each component owns, essentially building on it.
PingAuthorize evaluates the stable customer or relationship identifier, verified ownership, consent, jurisdiction, and enterprise policy. It then returns a reason-coded visibility decision. The resource-owning BU continues to decide whether the customer may perform an action.
PingAuthorize should consume rel_id and relationship context; it should not generate or master rel_id. CIAM authenticates the customer and carries rel_id as a claim with the minimum runtime trust context. MDM, as the Enterprise Relationship Registry, masters accepted links and aliases, and the operational profile serves them at runtime. This preserves Manulife's “enterprise coarse, BU fine” boundary without turning the PDP into another master-data store.
How it works
| Who is the customer? | ForgeRock CIAM authenticates them |
|---|---|
| What products or relationships are connected to them? | MDM holds accepted links under the customer's rel_id after binding evidence or a match/merge outcome has been verified; the operational profile serves them. |
| What may appear in the unified portal? | The BFF asks PingAuthorize: “May rel_id 123 be shown product ABC in this context?” PingAuthorize evaluates trusted attributes such as: verified product relationship, consent, jurisdiction, customer or relationship type, and enterprise policy. It returns allow or deny with an internal reason code. The BFF enforces that answer when composing the portal. |
| What may the customer do with the product? | The BU API still verifies the customer token and authorizes the specific account, read or transaction. |
Proposed Enterprise Visibility Decision Full Flow Diagram
Runtime path from authenticated portal request to an allowed product card · relationship facts and policy decisions remain separate
(Diagram below is a draft and is in the process of being cleaned up: Lucid Link. It predates Manulife's Oct 12 ruling: read its Enterprise Relationship Registry box as Informatica MDM and ECID as rel_id.)
rel_id is a key, not a permission. Using rel_id context does not mean rel_id itself grants access. rel_id is the stable key used to find trusted relationships and policy attributes. This prevents PingAuthorize from becoming a second customer master.
MDM, as the Enterprise Relationship Registry, governs the rel_id, aliases, provenance, status and effective dates of each accepted relationship, and the operational profile projects those facts to PingAuthorize. CIAM continues to carry only rel_id and the minimum runtime identity context. PingAuthorize consumes these facts with consent, jurisdiction and enterprise policy to decide product visibility; it does not master rel_id or relationships.
This follows Manulife's MDM-centric strategy and target draft rather than changing it:
- Informatica MDM, the Enterprise Relationship Registry:
rel_idlifecycle, accepted relationships, match/merge, survivorship and lineage. - Operational profile and ForgeRock IDM: event-fed copies for channel reads and the identifier crosswalk; neither matches nor mints.
What’s new
It’s important to call out what differs from Manulife’s architecture materials to easily communicate our recommendations. Compared with Manulife’s June strategy, much of the following is confirmation:
- PingAuthorize as PDP already exists in the strategy.
- The BFF as policy enforcement point already exists.
- Relationship, consent and jurisdiction are already policy inputs.
- The UCL HLD already says: “enterprise coarse, BU fine.”
The recommendation adds or changes three important things:
It aligns with an inconsistency.
The June strategy suggests PingAuthorize returns both visibility and action decisions. The UCL HLD says BUs own actions. This recommendation chooses the latter: PingAuthorize decides enterprise visibility; BUs retain object- and action-level authority.It feeds MDM from BU ownership events. Manulife has confirmed MDM as the registry. This recommendation asks each BU to emit ownership and end-of-relationship events into MDM's intake contract, rather than MDM learning of products in batch, so that a new product is linked to
rel_idwhen it is created.It makes the conceptual strategy executable.
It defines the actual policy question, enforcement point, reason-coded response and ownership boundaries.
Compared with the current dashboard MVP, the change is much larger. The ADS uses a manually populated BU Mapping table to infer what to display and calls downstream systems as service principals. An MVP that retains that protected-data aggregation path must add delegated customer context and resource-side authorization; a navigation-first MVP can remove the unsafe path instead.
The target-state trade-off is additional integration and governance: relationship data and policy inputs must remain current, PingAuthorize becomes a runtime dependency, and each BU must accept audience-bound customer tokens when its APIs are called on the customer's behalf. In exchange, the portal gets a defensible disclosure control rather than trusting a navigation table.
3. Propagation - One CIAM session, audience-bound tokens
MVP1 must choose one of two security paths. Open questions 12 and 17 are the sponsor and architecture decisions that select it.
| MVP path | Portal scope | Identity propagation | Resource authorization |
|---|---|---|---|
| A — Navigation-first (recommended) | Render approved links and launch independently secured BU applications; do not proxy protected BU data. | One CIAM browser session. Each BU application performs OIDC Authorization Code + PKCE and receives tokens for its own client and audience. | The BU application retains object, action and transaction authorization. |
| B — Protected-data aggregation | The portal BFF calls BU APIs for balances, claims or other protected customer data. | Delegated customer context through RFC 8693 token exchange. Tokens are restricted to the target BU audience. | The BU API validates the delegated subject and authorizes every object and action. A service principal plus ?ciamId= is insufficient. |
Path A is our MVP1 recommendation because it reuses the existing SSO handoff and preserves BU security boundaries with less delivery risk. After authenticating through ForgeRock CIAM, the customer selects a product and enters the BU application without another credential prompt when policy allows. The portal does not forward its token or supply identity through query parameters or caller-selected headers.
Path B is not a later enhancement if protected BU data remains in MVP scope. Token exchange, delegated customer context and BU resource-side authorization then become MVP controls. Front-channel SSO does not secure a server-to-server aggregation call.
Component Flow Diagram — customer identity, Manulife Canadadraft — not for client viewing
Benefits
Path A reuses ForgeRock CIAM and Manulife's existing OIDC SSO pattern, allowing customers to authenticate once while each BU application receives client- and audience-bound tokens and retains authorization control. It reduces delivery complexity and avoids dependency on rel_id, MDM or the full PingAuthorize programme.
The trade-off is less protected data displayed directly in the initial portal. In return, Manulife preserves BU security boundaries and avoids creating a shared integration service with broad access to customer data. Choosing Path B retains the aggregated experience but pulls token exchange, resource-side authorization, resilience and audit into the MVP critical path.
What’s new
The existing product-portal path already preserves customer identity through SSO. This recommendation makes that pattern explicit: the portal launches the BU application, which performs OIDC Authorization Code + PKCE against the shared CIAM session.
The new aggregation path instead uses service principals and supplies customer scope through values such as ?ciamId= or caller-selected headers. BU APIs can authenticate the application but cannot independently verify the customer.
Token exchange is unnecessary on Path A because the portal does not proxy protected BU data. It is mandatory on Path B, whether protected aggregation ships in MVP1 or a later release.
Responsibility model
Here is a summary of the positions by component:
| Component | ✅Responsible for | ❌Not responsible for |
|---|---|---|
| BU systems of record | Product facts against BU-local customer, account, policy or membership identifiers; relationship start, end and readiness events | Mastering the enterprise person identity or cross-BU policy |
| Informatica MDM, Enterprise Relationship Registry | rel_id lifecycle (issue, link, merge, unmerge, redirect, end of relationship); accepted identity-to-relationship-to-product links, aliases, evidence and provenance; match/merge, survivorship, lineage and stewardship | Authentication, runtime channel serving, financial-data disclosure decisions or originating BU product facts |
| ForgeRock IDM (ECR) | Event-fed crosswalk replica of rel_id and BU aliases | Matching or minting rel_id |
| ForgeRock CIAM | Authentication, recovery, shared SSO session, runtime subject context including the rel_id claim, and client-specific OIDC token issuance | Customer-product relationship mastery, full Customer 360 or entitlement policy |
| Identity and ownership projection | Current ownership view for navigation and policy input | Authorization decisions or source-of-record duties |
| Operational customer profile | Low-latency shared customer context for channels | Mastering or probabilistic identity resolution |
| PingAuthorize | Enterprise product-visibility decisions using identity, ownership, consent, and policy | rel_id issuance, ownership mastery or BU transaction rules |
| Portal BFF / enterprise PEP | Enforcing product visibility and Path A navigation; on Path B, presenting delegated customer context to BU APIs | Forwarding its own token or treating a mapping as permission |
| Inter API Mediation / token exchange | Customer delegation whenever protected BU data is aggregated, including MVP1 if Path B is selected | Owning customer or product records; the front-channel SSO launch |
| BU API / resource PEP | Object- and action-level authorization; validating delegated customer tokens on Path B | Trusting an unverified customer identifier from the caller |
| OneTrust | Consent system of record and runtime consent input | Identity resolution or authorization policy |
| Decision and ownership audit | Decision trace, ownership history, attestation and reconciliation evidence | Authoring ownership facts or policy |
| BU application / BFF | Its OIDC client, Authorization Code + PKCE flow, local session and BU transaction authorization. | Trusting portal-provided tokens or customer identifiers. |
Differences from the latest Unified Customer Architecture document
Compared with Manulife's proposal, this model does not remove MDM, the operational profile or the Ping identity stack, and it keeps MDM as the Enterprise Relationship Registry, as Manulife has ruled. It makes the BU authoritative only for its product facts and has it assert them into MDM, limits CIAM to authentication and runtime identity context, uses PingAuthorize for enterprise visibility, and gives BU applications one CIAM session with client- and audience-bound tokens.
The trade-off is more explicit integration ownership: every BU must emit a product-relationship signal with binding evidence into MDM and accept a delegated customer token when its APIs are aggregated. That coordination cost is what makes new-product links deterministic, and it avoids making MDM a channel read dependency, CIAM a customer-data warehouse, or a shared service principal a master key to cross-BU data. MDM does remain on the first-access path, since no dashboard renders until it issues or links rel_id.
Justifications (more to come)
The model follows established security boundaries, and the estate already points to it.
Decision and enforcement are deliberately separate. NIST SP 800-207 defines a policy decision point that evaluates enterprise policy and supporting information, with a policy enforcement point guarding the resource. Ping's own PingAuthorize architecture describes PDP and PEP responsibilities; it does not position PingAuthorize as an identity master. Keeping the customer subject at the BU API also satisfies OWASP API1:2023, which requires object-level authorization for every API request carrying an object identifier.
The recommendation preserves Manulife's layers and authority model. “Mastering does not serve UI; serving does not master” remains intact. A BU-authored onboarding fact can be linked through MDM's search-before-create without probabilistic matching when trusted evidence binds it to the CIAM subject, while historical ambiguity receives MDM match/merge. “Enterprise coarse, BU fine” becomes executable: PingAuthorize decides visibility, and the BU decides actions. The mediation proposal's mandatory JWT Exchange supplies propagation on Path B only; Path A uses front-channel CIAM SSO. ForgeRock, PingAuthorize, OneTrust and the existing exchange capability are retained, and MDM is the Enterprise Relationship Registry, as Manulife ruled (ADR-0006).
The same contracts support the next regulatory and technology demands.
- Canada's proposed Consumer-Driven Banking Regulations move financial-data sharing toward accredited, consented, API-based access. The FAPI 2.0 Security Profile provides a high-security OAuth profile for financial and other high-value APIs. Verified ownership, runtime consent, audience-bound tokens and resource-side enforcement are compatible foundations for that direction.
- The MCP authorization specification requires OAuth Resource Indicators so a token is explicitly issued for, and validated by, the target MCP server. The same audience-bound delegation model lets future AI agents act on behalf of a customer without receiving a reusable enterprise-wide token. AI remains another client of policy; it does not bypass consent or authorization.
- Reason-coded decisions, subject-preserving calls and immutable ownership history improve threat investigation, regulatory replay and negative testing now, independent of future channels.