AuthorizationController stub bodies need implementation + per-TP filtering

[dfcoffin]

Summary

web/api/AuthorizationController currently has two endpoints whose bodies return null (stubs marked //todo - complete implementation). PR C2a fixed the long-disabled AuthorizationControllerTest as a security-boundary-only check (verifies authentication + scope-based authorization), but the functional behavior still needs to be built.

Endpoints

Method	Path	Status
GET	/espi/1_1/resource/Authorization	Stub returns null — should return a paginated list of authorizations
GET	/espi/1_1/resource/Authorization/{authorizationId}	Stub returns null — should return a single authorization or 404

Required behavior

Both endpoints accept either of two scopes (post-PR C2a):

• SCOPE_DataCustodian_Admin_Access — DC admin (client_credentials)
• SCOPE_ThirdParty_Admin_Access — TP admin (client_credentials)

A customer-bearer (FB-scoped) token is rejected at the chain level (verified in PR C2a tests).

Per-TP filtering when called with SCOPE_ThirdParty_Admin_Access

A TP authenticating with its own client_credentials token MUST see only its own authorizations, not the full set. The current stub's commented-out logic calls authorizationRepository.findAll(...) unconditionally, which would expose every TP's authorizations to every other TP. This is the production-critical part of the implementation.

Implementation approach (suggested, not prescriptive):

String clientId = extractClientIdFromAuthentication(authentication);
boolean isDcAdmin = hasAuthority(authentication, "SCOPE_DataCustodian_Admin_Access");
Page<AuthorizationEntity> page = isDcAdmin
    ? authorizationRepository.findAll(pageable)
    : authorizationRepository.findAllByThirdParty(clientId, pageable);

For the single-id endpoint: findById(authorizationId) then verify ownership matches clientId (404 if not — don't leak existence).

Acceptance criteria

• GET /Authorization with SCOPE_DataCustodian_Admin_Access returns paginated list of ALL authorizations.
• GET /Authorization with SCOPE_ThirdParty_Admin_Access returns ONLY authorizations whose third_party matches the authenticating client.
• GET /Authorization/{id} with admin scope returns the authorization or 404.
• GET /Authorization/{id} with TP_Admin scope returns the authorization IFF it belongs to the authenticating client, else 404 (never 403 — no existence leak).
• Existing PR C2a security-boundary tests still pass.
• New functional MockMvc tests covering: admin sees all; TP sees only own; TP cannot see another TP's authorization (404).

Refs

• Surfaced during PR C2a (re-enabling the AuthorizationControllerTest that was @Disabled since PR feat: Modernize ESPI REST controllers (Issue #98, no auth-server migration) #116).
• The security-boundary gating was tightened in PR C2a; this issue tracks completing the functional body.

🤖 Generated with Claude Code

[dfcoffin]

Reference: GBA XSLT conformance scripts for per-FB filtering

The per-TP filtering work on the customer_resource_uri endpoint (and the per-FB granularity that PR C2b will surface in the Authorization Screen) is already conformance-tested by the GBA validator's Schematron/XSLT scripts. These are the authoritative reference for "given a token scope including FB_X, what fields must / must not appear in the response."

Location: D:\Dropbox\gbwebsites\dmdvalidator.greenbuttonalliance.org\conformance\ (per @donaldcoffin)

PII FBs (54–62) verified against XSLT contents:

FB	XSLT-tested resource	Asserted fields
54	cust:Customer	customerName
55	cust:Customer/cust:Organisation/cust:streetAddress	street, town, state/province
56	cust:CustomerAccount	accountId, contactInfo/streetAddress
57	cust:CustomerAgreement (linked from CustomerAccount)	agreementId
58	cust:ServiceLocation (linked from CustomerAgreement)	—
59	cust:ServiceSupplier (linked from CustomerAgreement)	—
60	cust:Meter	serialNumber
61	cust:EndDevice	serialNumber
62	cust:ProgramDateIdMappings (linked from CustomerAccount)	—

When implementing the customer_resource_uri endpoint, the response Atom feed should include the resource families for each granted PII FB and omit the rest. The XSLT files can be run against the implementation output to verify conformance.

The same mapping is what PR C2b's Authorization Screen uses to render one consent checkbox per PII FB requested.

[dfcoffin]

Reference: GBA XSLT conformance scripts for Energy FBs (54–62 PII addendum extended)

Beyond the PII FB conformance reference in the previous comment, the same GBA validator directory contains XSLT/Schematron tests for every Energy FB the system implements (1, 4, 5–11, 12, 15–17, 27, 28, 29, 51).

Location: D:\Dropbox\gbwebsites\dmdvalidator.greenbuttonalliance.org\conformance\

Per-FB verified mapping (resource family + asserted ReadingType discriminators):

Base FBs (mandatory for every grant)

FB	Resource	Asserted fields	Notes
01	espi:UsagePoint, espi:ServiceCategory, espi:LocalTimeParameters	structural	Energy-feed service identity / timezone
04	espi:MeterReading, espi:ReadingType, espi:IntervalBlock, espi:IntervalReading, espi:UsagePoint	structural	Meter readings registry
51	cust:LocalTimeParameters linked to cust:Customer	structural	Customer-feed timezone (analog of FB_01 for the customer feed)

Commodity FBs (ServiceCategory/espi:kind discriminator)

FB	Commodity	ReadingType profile	Customer-facing meaning
05	Electricity (kind=0)	commodity=1, flowDirection=1, kind=12, uom=72, accumBehaviour=4	Hourly delivered (Wh interval)
06	Electricity (kind=0)	accumBehaviour=12, kind=37 W + kind=12 Wh/Time	Peak demand + rate summation
07	Electricity (kind=0)	flowDirection=4 (Net), kind=12, uom=72	Net (consumption − generation)
08	Electricity (kind=0)	flowDirection=19 (Reverse), kind=12, uom=72	Export-back-to-grid (e.g., solar)
09	Electricity (kind=0)	accumBehaviour=1 (BulkQuantity), kind=12, uom=72	Cumulative register reads
10	Natural Gas (kind=1)	commodity=7, kind=12/58, uom=31/132/169/42/119	m³ / therms / BTU / ft³ / gallons
11	Water (kind=2)	commodity=9, kind=58, uom=128/119/42	gallons / m³ / ft³
29	Temperature (kind=10, GBA extension)	kind=46, uom=6	Celsius temperature readings (no XSD-defined ServiceKind)

Energy data-shape FBs (resource family discriminator, orthogonal to commodity)

FB	Resource	Field discriminators	Customer-facing meaning
12	espi:IntervalBlock, espi:IntervalReading, espi:ReadingType	interval data structure	Individual time-series interval reads
15	espi:UsageSummary	billingPeriod, currentBillingPeriodOverAllConsumption, overallConsumptionLastPeriod	Billing-period totals (current + previous)
16	espi:UsageSummary	adds billLastPeriod, costAdditionalLastPeriod, currency	Billed amounts with cost in customer currency
17	espi:ElectricPowerQualitySummary	(power-quality fields)	Voltage/frequency/PQ metrics
27	espi:UsageSummary	adds currentDayOverallConsumption, previousDayOverallConsumption, peakDemand	Daily totals + peak demand
28	espi:UsageSummary	adds billToDate, statusTimeStamp, title	Running bill-to-date status

Architectural implication for issue #141's implementation

The customer_resource_uri endpoint (the originally-named scope of this issue) is only one of two endpoints the per-FB filtering rules apply to. The full set:

1. customer_resource_uri — customer/PII data endpoint, gated by FBs 54–62 per the prior comment's table.
2. resource_uri / Subscription data endpoint — energy data endpoint, gated by FBs 1, 4, 5–11, 12, 15–17, 27, 28, 29, 51 per the table above.

The granted-scope filter on each endpoint must:

• For commodity FBs (5–11, 29): emit only MeterReading/ReadingType entries whose ServiceCategory/kind and ReadingType profile fields match a granted commodity FB.
• For data-shape FBs (12, 15–17, 27, 28): include or omit those resource families based on whether the matching FB is in the granted scope.
• For base FBs (1, 4, 51): always include (these are prerequisites for any meaningful response).

The XSLT files in the GBA conformance directory are the authoritative test reference — running them against the endpoint output validates correctness end-to-end.

This filtering is also what PR C2b's Authorization Screen uses to drive the customer-facing consent UI (one consent decision per PII FB, customer's checkbox decisions narrow the effective scope before token mint).