Broker and Auditor Access in a Global Onboarding App
GlobalTrust Bank's Pega onboarding application serves 4,000 internal staff and 300 external brokers. Internal fraud investigators must see all cases and full PII. Relationship managers must see only cases for their portfolio. Brokers must see only cases they submitted and must never see full SSN. Auditors need read-only access to all cases but no PII. The current design uses access groups and access of role to object (ARO) rules. Brokers are in a Broker access group with read access to the case class, so a broker who guesses a case URL can open another broker's case. An audit found 12 such accesses in one month. Authentication is SAML SSO for both populations. The bank also wants evidence that row-level and property-level controls are tested before each release.
1. Explain the access control design for broker case visibility and SSN masking, and why ARO alone is insufficient.
Read the worked answer
ARO is class-level: it can say that the Broker role may read the case class, but it cannot say which case rows or which properties. That is why a broker can open another broker's case by URL. Add an access control policy on the case class with a condition that matches the case's submitting broker to the operator ID. Keep the ARO for class access, but let the policy restrict row visibility.
For SSN, use a property-level control, not just a UI mask. Deny read on the SSN property for Broker and Auditor roles, or grant it only through a privilege held by fraud investigators. Apply the same checks to reports, search, and API responses, because a UI-only mask leaves other channels open. Auditors get read on case rows but no SSN property access.
2. What test cases and logging would prove the fix and prevent regression when new case types are added?
Read the worked answer
Test negative cases first: broker A opens broker B's case by direct URL, by API, by report, and by search; relationship manager opens a case outside the portfolio; auditor attempts to read SSN; fraud investigator reads all. Test both allow and deny outcomes, because a control that denies everything is also a failure.
Log security events for denied access and monitor them for patterns. Include these tests in the release regression suite and require a review of access control policies when a new case type is added. Put a checklist item in the release process that new case types inherit or explicitly define row-level and property-level controls. This prevents a future team from relying on an ARO alone and reopening the same gap.