R1.2 · Source enterprise visibility from PingAuthorize
| Theme | R1 · Identity and authorization |
| Domain | Identity and access management |
| Status | Proposed |
| Needs client validation | Yes |
| Reinforces | R1.1 |
| Supplied by | R1.3 — which sources the verified ownership projection this page's decision point reads |
| Anchored in | Assessment findings B-01, B-02, K-10 · condition 02 · question Q02 · the readiness review's cancellation list · the entitlement APIs recorded in the API landscape |
| Open questions | Takes a position on 17 and 41; depends on 12, 15, 23 and 33 |
| Deliverables | D1.2 · D2.1 · D2.4 |
Concern
The unified dashboard decides which of a customer's financial positions to fetch and display by reading a table somebody maintains by hand, and the workstream that would have replaced that table no longer exists.
The GARB ADS is consistent about the first part. Its scope statement excludes "centralized authorization capabilities." Its preservation list keeps "existing authorization models." Its Security section states "For MVP, authorization remains within individual product portals." And its authorization row commits the position outright:
No change to authorization for the MVP. Authorization remains enforced in existing product portals and applications. […] The unified dashboard will integrate the existing BU Mapping Service (owned by CIAM), which provides CIAM ID to product mapping. That mapping is created today via a manual customer product-linking process.
B-02 — entitlement rests on a manually maintained mapping table. The segment assessment rates this a blocker and draws the line precisely where it belongs:
A manually maintained mapping is acceptable for navigation. It is not acceptable for disclosure of Highly Confidential financial data without an integrity control, a change-audit trail, a periodic attestation or reconciliation cycle, a defined error path for stale or incorrect mappings, and negative test coverage proving a wrong mapping cannot surface another customer's balance. The ADS describes none of these.
Its closing sentence is the one that binds this page to R1.1: "With authorization no longer enforced downstream (B-01), mapping integrity is the control — and it is undocumented." K-10 records the same fact from the diagram: the architecture drawing shows BU Mapping as an automated lookup with no human step, "hiding the mapping-integrity requirements of B-02."
The plan to replace it was cancelled, not deferred
This is where the material stops reading as ordinary phasing. The readiness review's NOT-IN-SCOPE list for MVP1 names "Unified Entitlements · PDP · centralized authorization" and "Enterprise customer context token provider", which on its own implies a later phase holding them — and the ADS agrees, putting "PDP/UES authorization" in Phase 3. But the same deck's replan slide lists WS 1 Unified Identity MVP, User Profile requirements, Personalized Greeting requirements, and Profile Preferences and Identity & Access discovery among the workstreams cancelled in the CAUCE-to-CAUEX transition with "no CAUEX inheritor." Consent and Preferences (CAUEX-11) is the shape deferral actually takes here — still in Jira, in Analyzing, ownerless. The identity items are not in that shape.
So the manual table is not a stopgap with a successor. On the written record it is the design, and nothing is scheduled to take over from it.
The decision the MVP is hand-maintaining is already made somewhere else
The API landscape enumerates a Canada Digital Identity entitlements platform in production, on prod.digital-identity.aks.manulife.ca:
| Component | Registered operations |
|---|---|
int-cdt-cet-di-can-ent-api-{adv,cp,gb}-prod | POST /entitled — one decision endpoint per audience |
int-cdt-cet-di-can-ent-cons-{adv,gb}-prod-int | upsertPolicySet, retrievePolicySet, deletePolicy, deletePolicySet |
int-cdt-cet-di-can-entitlements-producer-prod | publishPolicySet |
That is a policy administration point, a distribution path and a per-audience decision endpoint — the shape of the thing the ADS defers to Phase 3 — already registered, already split by audience, and hosted by the same platform team that owns the BU Mapping Service at id.manulife.ca/mappings. Three business units run their own alongside it: gip-can-entitlement (/v1/Entitlements/GetUserByCiamID), rtl-can-entitlementproxy (/api/entitlements/username/{user}) and rtl-can-passportbff (/v2/admin/ondemand/entitlements/{ciamid}). Every one of them is keyed on the customer identifier the dashboard already holds.
Read this with the right caution. The inventory evidences that a service is registered at the gateway, not what it decides, how current its policy sets are, or whether cp means the customer portal — the inventory does not expand it. That is open question 33, and it is the first thing to establish. The claim this page rests on is narrower and survives the caution: a capability of this shape exists in the estate, owned by the same team, and no artifact in the corpus connects it to the unified dashboard.
How the path runs today
Click to open full size.
The entitlements platform and the BU Mapping Service sit side by side, both operated by the same platform, and only one of them is on the dashboard path. That adjacency is the whole recommendation.
Recommendation
Make enterprise product visibility for the unified surface a PingAuthorize decision, and demote the BU Mapping table to what the assessment says it is fit for — navigation.
Three properties, in this order:
One question, answered by a service. The dashboard asks may this verified identity be shown this business unit's position? and receives an answer from PingAuthorize, rather than reading a row and inferring one. Before rel_id is available the subject can be the CIAM ID already carried by the dashboard; later the same contract consumes rel_id and relationship context. This converts B-02 from a control gap into a control without coupling the decision interface to the identity key used today.
The answer is sourced, logged and attestable. The value of an entitlement service over a table is not the decision, it is everything around it: policy sets are published and versioned rather than rows edited, every decision is loggable against the identity that received it, and attestation runs against a policy rather than a spreadsheet's history. Condition 02's second branch demands exactly this list — "mapping integrity and attestation, change auditing" — as compensating controls. An explicit decision path, policy administration and audit record supply them as controls rather than as obligations somebody has to remember to discharge.
Visibility and action stay with separate authorities. PingAuthorize answers the enterprise question — can this identity see this product? — and the BFF enforces it when composing the unified view. After the portal launches the independently secured BU application through OIDC SSO, that application and its APIs answer the finer question — can this identity act on this resource? — using BU product rules. This is the UCL HLD's stated boundary, "enterprise coarse, BU fine." PingAuthorize consumes rel_id and relationship context; it does not issue or master rel_id.
Three things make this cheaper than the phrase "centralized authorization" suggests, and all three are worth putting in front of the client early:
- This is not the Phase 3 programme. PDP/UES authorization in Phase 3 arrives with
rel_id, MDM, consent and an enterprise relationship model behind it. What this page asks for is a visibility decision keyed first on the CIAM ID the dashboard already carries and later onrel_idand verified relationship context. Phase 3 makes the inputs richer; it is not a prerequisite for having a decision point. - The client's own conceptual architecture already draws it. The ADS's Policy and Enforcement layer "evaluates whether the requested action should be permitted using ABAC-based authorization policies", and the strategy names PingAuthorize with the enforcement point in the BFF tier. We are arguing about which release this lands in, not whether it belongs in the architecture.
- The alternative is a permanent obligation with no owner. Keeping the manual table as the disclosure control means carrying integrity, attestation, change-audit and negative-test coverage forever — and open question 14 records that nobody owns the shared runtime that would carry them.
What it looks like
Click to open full size.
Three things stay exactly where they are, and the drawing says so: ForgeRock still authenticates, the product portals and BU APIs still own servicing and transaction authorization, and manual product linking remains the MVP fallback.
What it changes
What the BU Mapping Service is for. It becomes a navigation projection — which tiles to consider rendering — rather than the control that decides which financial data may be disclosed. In the target state R1.3 supplies it from MDM's relationships through the operational profile; during transition the current mapping may remain its source. R1.1 keeps that transition on the safe side of the assessment's boundary: the mapping offers a link, and the BU application re-authenticates through the shared CIAM SSO session before protected data is served. This page gives the dashboard's display decision a source. Neither substitutes for the other.
What rel_id is for. rel_id, which the ADS calls ECID, is a stable policy input and runtime correlation key. MDM, as the enterprise relationship registry, issues and governs it (ADR-0006). CIAM carries it as minimum trust context, and PingAuthorize reads it. Moving from the current CIAM ID to rel_id must therefore be a non-breaking identity-key swap, not a new authorization contract.
What "no change to authorization" means. The statement becomes precise rather than contested. Today it asserts no change while the display decision has already moved into a new component. In the target split, the BFF enforces enterprise visibility while product portals and BU APIs retain servicing, object and transaction authorization.
What the portal hand-off does. The MVP architecture diagram routes each MFE out to its product portal over an arrow annotated sso, and K-05 records that those connectors carry no protocol, authentication method or data classification. R1.1 makes the contract explicit: the portal launches the BU application; that application starts its own OIDC Authorization Code + PKCE flow against the existing CIAM session and receives its own tokens. The portal does not forward a bearer token or customer identifier.
What WS 3 prices. Integrating an existing decision endpoint is a different estimate from building an entitlement capability, and the difference is most of the cost. Which of the two we are pricing depends on question 33, which is why it is a WS 2 answer and not a WS 3 one.
What we are not recommending
Building a second entitlement service. The registered decision endpoints must be mapped to PingAuthorize — implementation, adapter or predecessor — before any build is assumed. If they do not provide the required visibility decision, record the gap in D2.4 and let the identity platform own it. The alternative is another portal-shaped authorization model.
Waiting for rel_id, MDM and consent. Those make the decision inputs richer and are Phase 2 and 3 work with their own dependencies. Sequencing a control behind them means the MVP ships B-02 and holds it for as long as those phases slip.
Centralizing authorization for transactions. This is scoped to the display decision the aggregation surface newly makes. Servicing and transactional authorization stay where the ADS puts them, in the product portals, and we agree with that.
Replacing the manual linking journey. Automatic product linking is explicitly out of MVP1 scope and we are not reopening it. A customer still links products the way they do today; what changes is what the resulting record is trusted to authorize. That exclusion is an MVP1 one and does not hold at target-state altitude — R1.3 argues the record should be written by the business unit that creates the relationship rather than by the customer, and this page's decision point is what reads it.
Replacing ForgeRock. As in R1.1 — the assessment rates reusing CIAM unchanged as the correct risk decision and we agree. This changes where a permission is decided, not who authenticates.
About these two drawings. They are reference sketches, drawn in the format of a prior engagement's SSO assessment so the picture is legible to an audience that has read one before. The versioned source of truth is the Component Flow Diagram, whose v1-to-working delta carries the same change set under validation. Edit the diagram source first; these are regenerated by hand and will not follow it.
Dependencies and open questions
- Open question 33 — what the registered entitlement APIs actually decide, whether
cpis the customer portal, and how they relate to the unexpanded UES in the ADS's Phase 3 scope. The whole cost argument turns on this and it is the cheapest item on the list to close: it is one conversation with the Canada Digital Identity platform team. - Open question 15 — who, if anyone, inherited WS 1 Unified Identity MVP. If something did, this recommendation is addressed to it rather than to the dashboard programme.
- Open question 12 — whether MVP1 scope is fixed at no centralized authorization. If it is fixed, this becomes the first item of the phase that follows, and B-02's compensating controls have to be designed and owned in the interim.
- Open question 23 — whether PingAuthorize is funded and staffed. The target product depends on the answer; the need for an explicit visibility decision does not.
- Open question 17 — the authorization question this and R1.1 sequence around for a navigation-first MVP. It returns unchanged if protected BU data is aggregated.
- Open question 41 — this page's position is PingAuthorize for enterprise visibility, enforced by the BFF; the launched BU application and its APIs retain object- and action-level authorization.
- Confirmation that the BU Mapping Service and the entitlements platform share an owner, which is inferred from hostnames and registration prefixes rather than stated anywhere. Tracked in client requests.