GOV-ONT-001 — Define the project authorization boundary
| Field | Value |
|---|---|
| Status | Improvement backlog; current shared-namespace behavior is source-verified |
| Severity | Not classified as a current defect |
| Components | sparqd/ontology, sparqd/bff-api, sparqd/oqullus, identity policy |
| Associated issues | sparqd/ontology-backend#13 |
Concrete observed case
All platform personas are mapped to the Ontology OAuth client. Backend project
list, read, create, and archive operations have no project membership check.
Object, branch, and Cube context reads accept a caller-selected project_id.
Expected condition
For the current product, explicitly document projects as shared organizational namespaces. If project isolation is introduced, authorize every metadata, mutation, proposal, workbook, notification, Cube-model, and semantic-query operation against one canonical project membership and role model.
Why it matters
Naming a project as an isolation boundary before policy exists would create a false security promise. Ontology metadata can reveal business definitions even when Ranger correctly denies the caller's physical data query.
Existing controls and workarounds
Authentication limits the service to mapped realm personas. Branch-owner checks limit working-branch mutation, and Ranger authorizes physical queries by the effective user. Neither control creates project-scoped metadata isolation.
Alternatives considered
- Recommended for now: label projects as shared namespaces and keep the improvement in Backlog.
- Add project memberships and project roles when a real isolation use case is accepted; apply them centrally to every route and Cube context.
- Infer access from branch ownership — rejected because it does not cover main, project administration, reads, workbooks, or queries.
Component involvement
- Ontology backend owns the authoritative project policy decision.
- BFF propagates identity and must not invent a separate role model.
- Oqullus presents only actions allowed by the backend decision.
- Trino/Ranger remains a distinct physical-data authorization layer.
Reproduction and verification
Follow ONT-S005.
Resolution conditions
Close the backlog item when the product either formally retains shared namespaces with accurate UI/documentation or implements and tests project policy across every listed resource and query path.
Validation and blockers
The current shared implementation is known. The future tenant/project isolation requirement, role matrix, migration behavior, and policy authority require a product and security decision.