Fix/rbac sensor create hardening

[bhudevbhanpuriya]

Summary

This PR fixes an access control gap in the POST /Sensors endpoint by introducing explicit RBAC enforcement at the API layer and adding regression tests to validate correct behavior.

Previously, low-privilege users (e.g., viewers) could reach the sensor creation flow without a strict endpoint-level authorization check.

---

Problem

The sensor creation endpoint did not enforce a clear role-based allow-list.
Authorization depended on downstream behavior, which could allow unintended access and lead to inconsistent enforcement.

As a result, users with insufficient privileges could potentially create sensor entities.

---

Root Cause

Missing explicit RBAC validation at the endpoint level for the CREATE_SENSOR operation.

The system relied on implicit or indirect checks instead of enforcing a deterministic authorization gate.

---

Changes

• Added explicit role-based allow-list for POST /Sensors
• Enforced early rejection for unauthorized roles (fail-fast approach)
• Introduced regression tests covering:
  • deny path for low-privilege roles (e.g., viewer)
  • allow path for authorized roles (e.g., admin/editor)

---

Behavior before v after

sequenceDiagram
    title RBAC Fix: Prevent Viewer from Creating Sensor

    participant U as User (Viewer)
    participant API as API Server
    participant RBAC as RBAC Check
    participant DB as Database

    U->>API: POST /Sensors
    API->>API: Validate Token (Viewer)

    alt BEFORE (Bug - Missing RBAC)
        Note right of API: No role check
        API->>DB: Insert Sensor
        DB-->>API: Success
        API-->>U: 201 Created ❌
    else AFTER (Fixed - RBAC enforced)
        API->>RBAC: Check CREATE_SENSOR
        RBAC-->>API: Denied
        API-->>U: 403 Forbidden ✅
    end

Loading

---

Why This Matters

• Prevents unauthorized sensor creation
• Ensures consistent and predictable RBAC enforcement
• Strengthens security by eliminating implicit authorization paths
• Improves auditability and maintainability of access control logic

---

Testing

• Added focused regression tests for:
  • unauthorized access (viewer → denied)
  • authorized access (admin/editor → allowed)
• Verified updated code paths compile cleanly
• Note: local execution may require installing pytest

---

Backward Compatibility

• No changes to API contract for authorized users
• Only tightens behavior for unauthorized roles (expected security fix)

---

Future Improvements (Optional)

• Extend similar explicit RBAC enforcement to other write endpoints
• Centralize permission checks for consistency across services

---

Solves #119

[bhudevbhanpuriya]

this work has been continued in #121 with some further refinements.

Please feel free to review whichever is more convenient; #121 contains the most recent updates.