Robert Bond
+278
-6
@@ -18,15 +18,287 @@ Adoption Planning
|
||||
|
||||
### Next Recommended Architecture Stream
|
||||
|
||||
Portal API Security & Access Boundary Assessment
|
||||
Authorization architecture stream complete.
|
||||
|
||||
Next recommended architecture stream:
|
||||
|
||||
Portal authorization hardening / consistency planning (documentation-first, implementation only by explicit approval)
|
||||
|
||||
### Objectives
|
||||
|
||||
- endpoint inventory
|
||||
- authenticated/public classification
|
||||
- ownership validation review
|
||||
- access-control consistency review
|
||||
- security boundary assessment
|
||||
- record completed assessment conclusions
|
||||
- preserve stable authorization architecture model
|
||||
- use the model as a baseline for future hardening/change review
|
||||
|
||||
## Portal API Platform Assessment Status (2026-06-20)
|
||||
|
||||
### Stream status
|
||||
|
||||
**Portal Integration Contract & API Platform Assessment: COMPLETE**
|
||||
|
||||
### Consolidated architectural conclusion
|
||||
|
||||
The PEDW API platform is large in route count but materially smaller in underlying structure than the file count first suggests.
|
||||
|
||||
At an architecture level it is best understood as:
|
||||
|
||||
```text
|
||||
Large route surface
|
||||
↓
|
||||
small route-family vocabulary
|
||||
↓
|
||||
small contract-shape vocabulary
|
||||
↓
|
||||
small implementation-style vocabulary
|
||||
```
|
||||
|
||||
The main architectural and maintenance issue is therefore not discovery of a fundamentally different API architecture.
|
||||
|
||||
It is primarily:
|
||||
|
||||
- findability
|
||||
- ownership clarity
|
||||
- consistency and reuse discipline
|
||||
|
||||
### Stable route-family model
|
||||
|
||||
The completed assessment supports the following stable API platform families:
|
||||
|
||||
- CRM relay routes
|
||||
- storage/blob routes
|
||||
- finalisation/orchestration routes
|
||||
- email/notification routes
|
||||
- document download routes
|
||||
- auth/session routes
|
||||
- admin/internal routes
|
||||
- middleware/helper routes
|
||||
- local utility/meta routes
|
||||
|
||||
### Stable contract-shape model
|
||||
|
||||
The completed assessment supports the following repeated contract shapes:
|
||||
|
||||
- Public CRM read
|
||||
- User-owned CRM read
|
||||
- CRM create
|
||||
- CRM update/patch
|
||||
- CRM delete
|
||||
- Proxy/pass-through
|
||||
- Lookup/config/support
|
||||
- Hybrid upsert/orchestration
|
||||
- Storage read/write/delete
|
||||
- Queue/finalisation
|
||||
- Notify send / notification orchestration
|
||||
|
||||
### Stable implementation-style model
|
||||
|
||||
Three main implementation styles explain most of the API surface:
|
||||
|
||||
1. **Newer helper-oriented**
|
||||
- `relayGet(...)`
|
||||
- `relayGetData(...)`
|
||||
- `respondSuccess(...)`
|
||||
- `respondError(...)`
|
||||
- relay policy presets
|
||||
2. **Older direct-wrapper**
|
||||
- `getToken()`
|
||||
- direct `axios(config)`
|
||||
- manual `WEBAPI_URL + queryUrl + hashAPIPath(queryUrl)`
|
||||
3. **Orchestration-heavy**
|
||||
- finalisation routes
|
||||
- email aggregation routes
|
||||
- storage + queue + CRM side-effect routes
|
||||
|
||||
These older patterns are not inherently incorrect; they reflect prior delivery constraints. The key future discipline is whether they should be copied forward when shared helper patterns already exist.
|
||||
|
||||
### Folder drift and maintenance hotspots
|
||||
|
||||
Stable drift model:
|
||||
|
||||
- low drift: `documents`, `admin`, `middleware`, top-level utility/meta
|
||||
- low/moderate drift: `auth`
|
||||
- moderate drift: `email`
|
||||
- high drift: `endpoint`, `file`
|
||||
|
||||
Highest maintenance hotspots:
|
||||
|
||||
- **high:** `pages/api/endpoint`, `pages/api/file`
|
||||
- **medium-high:** `pages/api/auth`, `pages/api/middleware`
|
||||
- **medium:** `pages/api/email`
|
||||
- **lower:** `pages/api/documents`, `pages/api/admin`
|
||||
|
||||
### Proven / not proven status
|
||||
|
||||
#### Proven
|
||||
|
||||
- the API platform assessment is representative at the pattern level
|
||||
- route count overstates true structural diversity
|
||||
- most routes are explained by a small number of repeated route families, contract shapes, and implementation styles
|
||||
- the main maintenance problem is findability and ownership clarity
|
||||
|
||||
#### Not proven
|
||||
|
||||
- no full route-by-route inventory was produced
|
||||
- no route consolidation safety assessment has been performed
|
||||
- no implementation readiness decision has been approved
|
||||
- no route movement or removal is recommended at this stage
|
||||
|
||||
### Programme guidance
|
||||
|
||||
This stream should now be considered complete.
|
||||
|
||||
If future work is approved, it should be framed as:
|
||||
|
||||
- API Route Map / Maintainer Guide planning
|
||||
- API rationalisation planning
|
||||
|
||||
and not as implementation work by default.
|
||||
|
||||
## Portal Authorization Architecture Status (2026-06-19)
|
||||
|
||||
### Stream status
|
||||
|
||||
**Portal API Security & Access Boundary Assessment: COMPLETE**
|
||||
|
||||
### Consolidated architectural conclusion
|
||||
|
||||
PEDW currently exhibits a **distributed authorization model**.
|
||||
|
||||
The dominant observed pattern is:
|
||||
|
||||
```text
|
||||
Identity established
|
||||
↓
|
||||
Ownership scope established
|
||||
↓
|
||||
Ownership identifier propagated
|
||||
↓
|
||||
Integrity controls applied
|
||||
↓
|
||||
Operation executed
|
||||
```
|
||||
|
||||
rather than a uniformly route-local model where identity and ownership are re-derived and re-proven inside each final handler.
|
||||
|
||||
### Principal authorization roots
|
||||
|
||||
#### Public anonymous
|
||||
|
||||
```text
|
||||
Anonymous
|
||||
→ public search
|
||||
→ public case viewing
|
||||
```
|
||||
|
||||
#### CRM-owned data
|
||||
|
||||
```text
|
||||
NextAuth session
|
||||
→ session.user.email
|
||||
→ getPortalLogin(email)
|
||||
→ CRM Contact
|
||||
→ CRM relationships
|
||||
→ CRM operations
|
||||
```
|
||||
|
||||
#### Draft / storage-owned data
|
||||
|
||||
```text
|
||||
NextAuth session
|
||||
→ session.user.id
|
||||
→ user-specific storage container
|
||||
→ draft JSON
|
||||
→ uploaded files
|
||||
```
|
||||
|
||||
### Integrity and execution controls
|
||||
|
||||
#### Signed hash
|
||||
|
||||
The signed hash most clearly provides:
|
||||
|
||||
- route integrity
|
||||
- query integrity
|
||||
- parameter integrity
|
||||
- identifier integrity
|
||||
|
||||
It should be understood as:
|
||||
|
||||
> an integrity control rather than an object-authorization control.
|
||||
|
||||
#### Azure Storage execution
|
||||
|
||||
```text
|
||||
PEDW API
|
||||
→ Azure SDK
|
||||
→ storage account credentials
|
||||
→ Azure Storage
|
||||
```
|
||||
|
||||
Users do not directly access Azure Storage in the reviewed architecture.
|
||||
|
||||
#### Azure Relay execution
|
||||
|
||||
```text
|
||||
PEDW API
|
||||
→ signed hash
|
||||
→ Azure Relay
|
||||
→ CRM
|
||||
```
|
||||
|
||||
Relay hash validation is a route/path integrity mechanism.
|
||||
|
||||
Relay-to-CRM authentication remains out of scope for this architecture conclusion.
|
||||
|
||||
### Proven / not proven status
|
||||
|
||||
#### Proven
|
||||
|
||||
- distributed authorization model exists
|
||||
- ownership is generally established upstream
|
||||
- identifiers are propagated downstream
|
||||
- route-local referential verification is not consistently visible
|
||||
- storage ownership is rooted in `session.user.id`
|
||||
- CRM ownership is rooted in CRM Contact identity
|
||||
- signed hash strengthens integrity controls
|
||||
- storage execution is server-mediated rather than direct browser-to-storage
|
||||
|
||||
#### Not proven
|
||||
|
||||
- no confirmed exploitability
|
||||
- no demonstrated User A → User B mutation
|
||||
- no demonstrated authorization bypass
|
||||
- no evidence that prior OWASP assessments, health checks, or penetration tests are invalid
|
||||
- no evidence of direct browser-to-storage or direct browser-to-CRM access
|
||||
|
||||
### Risk characterization
|
||||
|
||||
The completed stream should be understood primarily as:
|
||||
|
||||
- architectural integrity risk
|
||||
- auditability risk
|
||||
- maintainability risk
|
||||
- future-change risk
|
||||
|
||||
It should **not** currently be characterised as:
|
||||
|
||||
- a confirmed vulnerability
|
||||
- a demonstrated exploit
|
||||
- broken authorization
|
||||
|
||||
unless materially new evidence emerges.
|
||||
|
||||
### Programme guidance
|
||||
|
||||
No immediate remediation programme is recommended on current evidence alone.
|
||||
|
||||
If future work is approved, it should be framed as:
|
||||
|
||||
- authorization hardening
|
||||
- consistency improvements
|
||||
- maintainability improvements
|
||||
|
||||
rather than emergency security remediation.
|
||||
|
||||
## Runtime Topology
|
||||
|
||||
|
||||
Reference in New Issue
Block a user