Enterprise ID and Entitlement — Recommendation for Review

Prepared for	Gopi Balasingam, Chief Architect
Purpose	First review of Konrad's recommended enterprise identity and entitlement model
Status	Draft for feedback. Revised 2026-10-12 for one client ruling: MDM is the enterprise relationship registry, and ECID is rel_id (ADR-0006)
Architecture	Current state, Manulife proposal and Konrad recommendation

Problem statement — authentication succeeds, but customer authority does not survive

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.

A representative flow illustrates the problem:

1. A customer signs in through ForgeRock CIAM and receives a valid customer identity.
2. The dashboard reads a manually populated CIAM-ID-to-product mapping to decide which products to retrieve and display.
3. The dashboard BFF and Integration API call downstream services as service principals. The customer's authenticated subject does not survive both new hops.
4. 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, customer scope is supplied as a request parameter.
5. 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 — one label currently covers three different contracts

Observation 3 separates “enterprise ID and entitlement” into three questions:

Theme	Question	Current answer
Resolution	Which products does this identity hold?	The customer creates links manually
Decision	May this identity be shown this product?	The dashboard infers an answer from the mapping
Handoff	How does the customer enter the BU security boundary?	SSO for a launched BU app; service principal for aggregated API calls

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.

The material does not yet align on how those components reach the target:

• The ADS already shows two different hand-offs: product applications retain authenticated customer identity through existing SSO federation, while the new aggregation path replaces the customer with a service principal. Those are different release shapes and need different controls.
• 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.

Recommendations — give resolution, decision and handoff separate owners

Adopt the third panel in the architecture comparison as the recommended responsibility model. It retains Manulife's selected identity products and four-layer architecture, but changes where ownership originates, what PingAuthorize decides, and how the portal hands the customer to the resource-owning BU application.

1. Resolution — BU-authored ownership, with MDM for ambiguity

The system that creates or terminates a product relationship should emit that fact. For a new enrolment, account or policy, the BU already knows the customer identity and can publish a deterministic ownership event containing source, subject, product, start or end, and provenance. MDM, as the enterprise relationship registry, accepts it. It issues or reuses rel_id with a deterministic search before create, records the verified links, source identifiers and provenance, and publishes the fact for the operational profile to project for navigation and policy.

The same MDM handles the hard case: legacy or back-book records where identities conflict, match confidence is uncertain, survivorship is required, or stewardship and consent are needed. Both paths end in MDM. Only the back-book path needs probabilistic matching, and neither puts MDM on the runtime read path.

Manual linking remains a controlled exception path for holdings a BU cannot yet assert or events that fail. It should be retired by measured coverage, not by target-state date.

2. Decision — PingAuthorize for enterprise visibility, using rel_id context

The portal BFF should ask an explicit policy question: “May this identity be shown this product?” PingAuthorize evaluates the stable customer or relationship identifier, verified ownership, consent, jurisdiction and enterprise policy, 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. MDM is authoritative for verified links, source identifiers and resolution, and CIAM carries the minimum trust context needed at runtime. This preserves the client's “enterprise coarse, BU fine” boundary without turning the PDP into another master-data store.

3. Handoff — one token contract, one CIAM SSO

For MVP1, make the portal a trusted launcher rather than a proxy for protected BU data. When a customer selects a product, the portal opens the independently secured BU application. That application starts its own OIDC Authorization Code + PKCE flow against ForgeRock CIAM. The existing CIAM session supplies SSO, normally without another credential prompt; the BU application receives tokens issued for its own client and audience, establishes its own session, and retains object-, action- and transaction-level authorization.

“One token” means one enterprise token contract — issuer, subject semantics, assurance context, signing and lifecycle rules — not one bearer-token instance reused across applications. The portal must not pass its access token, a customer identifier in a query string, or a caller-selected identity header to the BU application.

This launch-first path is safe only while the portal limits itself to navigation and approved card metadata. If a later release aggregates balances, claims or other protected BU data, SSO is not delegation: that API path still requires audience-bound token exchange or the full compensating controls required by the segment assessment.

Responsibility model

Component	Responsible for	Not responsible for
BU systems of record	Product facts; ownership start, end and readiness events	Enterprise identity matching or cross-BU policy
Informatica MDM — enterprise relationship registry	rel_id issuance and lifecycle; verified identity-to-relationship-to-product links, source identifiers and provenance; matching, merge, survivorship, lineage and stewardship	Runtime serving, originating product ownership or financial-data disclosure decisions
ForgeRock CIAM	Authentication, recovery, shared SSO session and client-specific OIDC token issuance under one token contract	Full customer 360, product mastery 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	Request and enforce the visibility decision; render approved navigation and initiate the BU-app launch	Acting as an identity provider, forwarding its token or proxying protected BU data in the launch-first release
BU application / BFF	Own OIDC client; start Authorization Code + PKCE; establish its local session; enforce BU actions and transactions	Trusting a portal token or customer ID passed in the launch request
Inter API Mediation / token exchange	Future delegated API path when the portal aggregates protected BU data	Participating in the front-channel SSO launch
BU API / resource PEP	Enforce object- and action-level access within the BU trust boundary; later accept a delegated customer token if aggregation is introduced	Trusting an unverified customer identifier from the portal
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

Compared with Manulife's proposal, this model does not remove MDM, the operational profile or the Ping identity stack. It keeps MDM as the relationship authority, makes the BU the author of the ownership facts MDM receives, limits CIAM to identity and trust context rather than a full 360, uses PingAuthorize for enterprise visibility rather than rel_id, and makes Manulife's existing dashboard-to-product SSO path the explicit first-release handoff.

The trade-off is less customer data composed on the first-release dashboard and a visible transition into the BU application. In return, each BU keeps its proven authorization boundary, the customer authenticates once, and MVP1 avoids making a shared service principal a master key to cross-BU data. BU-authored ownership signals and common OIDC client standards remain cross-BU coordination costs.

Justifications — the model follows established security boundaries and the estate already points to it

The SSO path is already Manulife's documented path. The ADS specifies OIDC Authorization Code + PKCE for CIAM and marks Unified Dashboard → Product Portals as existing SSO federation carrying authenticated customer identity. The UCL HLD names universal authentication, SSO, token minting and session management as one enterprise capability. The recommendation selects that path for MVP1 rather than inventing another identity handoff.

One token contract does not mean one shared token. Each portal or BU application receives tokens for its own client and audience from the same trusted issuer under the same enterprise profile. That preserves BU isolation while CIAM's browser session provides the one-login experience. Passing one portal bearer token across every application would weaken, not implement, the decision.

Decision and enforcement remain 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. PingAuthorize determines which product link the enterprise surface may show; after SSO launch, the BU application and its APIs retain object-, action- and transaction-level authorization.

The recommendation reconciles rather than replaces Manulife's architecture. “Mastering does not serve UI; serving does not master” remains intact. The deterministic onboarding link no longer waits for back-book resolution, and both it and historical ambiguity land in MDM. “Enterprise coarse, BU fine” becomes executable: PingAuthorize decides visibility, and the BU decides actions after an OIDC SSO launch. ForgeRock, PingAuthorize, OneTrust and the existing token-exchange capability are retained; exchange becomes the later answer if protected data moves back onto the aggregated surface.

Feedback requested

1. Confirm “one token, one SSO” as one enterprise OIDC/OAuth contract and one ForgeRock CIAM SSO domain, with separate client- and audience-specific tokens rather than one reusable bearer token.
2. Confirm the owner and system of record for the enterprise relationship registry.Answered: Informatica MDM (ADR-0006).
3. Endorse the split, inside MDM, between deterministic BU-authored provisioning links and probabilistic resolution of ambiguous or legacy links.
4. Confirm that MVP1 is navigation-first: selecting a product launches an independently secured BU application through OIDC SSO, and protected BU data is not aggregated until customer delegation is designed.