fix: unify consent ownership checks for OBP-native reads and Berlin Group authorisation

[hongwei1]

Consent ownership was decided three different ways across the codebase and, on the two Berlin Group calls that actually bind a consent to a person, not at all. This fixes both remaining gaps: the OBP-native read compared against the wrong subject and hid a PSU's own consent from them, and the Berlin Group authorisation pair let any authenticated caller claim a consent that was not theirs.

Structure follows #57: each rule is a named function in ConsentUtil, argued in its scaladoc and testable without standing up a request. The rules themselves are derived separately per standard — where they agree, the agreement is stated rather than assumed.

By file

code/api/util/ConsentUtil.scala

• checkObpConsentUserAccess — new. The OBP-native read's rule: a bound consent belongs to the human the request is on behalf of; an unbound one stays readable. The second half is deliberate and load-bearing, not inherited sloppiness — this endpoint is where a PSU inspects a consent before authorising it, and the app doing the inspecting belongs to the PSU, not to the TPP that lodged the consent, so it is a different Consumer by design. Adding the Consumer fallback the two standards use would break the journey. That divergence is why this is its own function rather than a third caller of the shared rule, and the residual it leaves open (an unbound consent's metadata is readable by anyone who knows its id) is written down in the scaladoc.
• checkBerlinGroupConsentAccess — new. Derived from the Implementation Guidelines' own blanket rule, §4.11 API Access Methods, p.24: "all methods submitted by a TPP, which are addressing dynamically created resources in this API, may only apply to resources which have been created by the same TPP before." A consent and its authorisation sub-resources are exactly that, which is already what deleteConsent and getConsentInformation enforce inline in the same file. The PSU half — no taking over a consent someone else authorised — rests on the spec delegating PSU identity to the ASPSP where it defines PSU-ID: "the ASPSP might check whether PSU-ID and token match, according to ASPSP documentation."
• psuOrLodgingTppRefusal — the rule UK and Berlin Group turned out to share, extracted from checkUKConsentAccess, which becomes a thin delegate with its scaladoc untouched. The two derivations are different (UK's rests on its Endpoints table marking these calls Client Credentials; BG's on the blanket same-TPP rule plus SCA-time binding), so both keep their own argument and only the mechanism is shared. No behaviour change for UK.
• genuinePsu — extracts the pseudo-user filter 6060f4252 left duplicated inline, as that commit said it would once this file was free. Required, not tidying: see the trade-off note below.

code/api/v5_1_0/Http4s510.scala — getConsentByConsentId now asks checkObpConsentUserAccess with cc.humanUser instead of comparing against cc.userId. cc.userId returns the authenticated principal, which under Consent-Id/Consent-JWT authentication is the per-consent shadow user, so the comparison could never match a consent's real owner.

code/api/berlin/group/v1_3/Http4sBGv13AIS.scala — the guard is added to both startConsentAuthorisationAll and updateConsentsPsuDataAll, before any side effect. Guarding only the PUT would have been half a fix: the POST is what mints the SCA challenge, so an unguarded POST lets a caller raise a challenge on any consent id and then answer their own. Both handlers dispatch on the body shape, and the guard sits in the transactionAuthorisation branch — the other three variants return mocked responses and never reach a consent.

Tests — two new suites rather than edits to existing files, so the diff does not collide with in-flight work on those files.

Testing

Both gaps were pinned red before the fix. With the new ConsentUtil functions present but the two call sites reverted, the four behavioural scenarios failed with exactly the symptoms described above:

BerlinGroupV13ConsentAccessTests  A second TPP cannot start an authorisation ...  201 did not equal 403
BerlinGroupV13ConsentAccessTests  A second TPP cannot answer an authorisation ...  400 did not equal 403
BerlinGroupV13ConsentAccessTests  A second PSU ... cannot re-bind ...              201 did not equal 403
ConsentOwnershipTests            The PSU may read their own consent ...            404 did not equal 200

With the call sites restored: 24/24 across the two new suites (20, plus the four genuinePsu contract scenarios added in the third commit).

Consent-family regression — Berlin Group, all UK Open Banking, and the OBP-native consent suites, 21 wildcardSuites: 487 succeeded, 0 failed across 42 suites. That set includes the Berlin Group end-to-end SCA regression and UKOpenBankingV401ConsentAccessTests from #57, both untouched.

Full local suite (./run_tests_parallel.sh, JDK 25): 3309 tests, 0 failures, 0 errors, 0 skipped — all shards passed. CI on the fork: compile, report and all 9 test shards green.

Trade-offs and behaviour changes

Tightening — Berlin Group. POST /consents/CONSENTID/authorisations and PUT .../AUTHORISATIONID now return 403 OBP-35015 when the caller's Consumer did not lodge the consent, and 403 OBP-35023 when a genuine PSU tries to take over a consent already bound to someone else. Both previously succeeded. A TPP that lodges and authorises under one Consumer — which is what the standard describes and what the end-to-end suite exercises — is unaffected; the Berlin Group journey stays green.

Loosening — OBP-native. GET /obp/v5.1.0/user/current/consents/CONSENT_ID now resolves the human behind the request, so a call authenticated by a consent can read that consent. It previously returned OBP-35001. Reads by an unrelated user are unchanged and still 404.

Why genuinePsu is load-bearing. A client-credentials token does not leave cc.user empty — it resolves to an auto-vivified pseudo-user keyed on the caller's own client key. Feeding that to the guard as if it were a PSU would refuse a legitimate TPP polling its own bound consent, which is precisely the Redirect approach, where the PSU authenticates at the ASPSP rather than through the TPP. There is a scenario pinning this discriminating case.

genuinePsu — contract

Spelled out because follow-up work on the Berlin Group authorisation handlers depends on it. genuinePsu(cc): Option[User] returns:

session	result
no user at all (cc.user empty)	None
only the consumer's own pseudo-identity (user.idGivenByProvider == cc.consumer.key)	None
a genuine PSU (OIDC / DirectLogin / OAuth1 session)	Some(user)
a pseudo-user with no consumer identified on the call	Some(user) — no key to compare against

So None is the normal, expected answer for a pure client-credentials call, which per the standard is what these two Berlin Group endpoints see: the caller is the TPP, and the PSU's factors travel in the body (psuData / scaAuthenticationData), never in the session. checkBerlinGroupConsentAccess is written for that: a None caller skips the PSU comparison entirely and is judged on the Consumer alone.

The last row is the one degenerate case, and it fails closed rather than open: with no consumer identified, callerConsumerId is also None, so a bound consent is refused on the PSU half and an unbound one on the Consumer half. All four rows are pinned by tests rather than left to the scaladoc, since narrowing them later would silently break the work built on top.

What this does not do: the val u = cc.user.openOrThrowException(AuthenticatedUserIsRequired) at the top of both handlers is untouched and still there. The new guard does not depend on it — it reads the session through genuinePsu instead — but that line will still throw once a client-credentials token stops auto-vivifying a user. Reworking it belongs with the handler rework, not here.

Deliberately not fixed here. The same shadow-user comparison still exists in revokeMyConsent, revokeConsentAtBank, v3.1.0 revokeConsent, and the two UK authorise guards in Http4s510. They are a loosening in the same direction rather than a hole, and were left out to keep this diff to the two gaps it set out to close.

Relationship to other PRs

Built on #57 (checkUKConsentAccess, refactored here onto the shared rule) and #60 (which established, for the Berlin Group read twins, that the PSU never calls the API — the premise the Consumer half of the new guard relies on). Both merged before this branch was cut; it is based on develop-obp at b5d556d20 and needs no rebase.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud