Skip to content
SENS Platform Docs

Security Model

This document defines initial security principles.

Important trust boundaries:

  • User browser to platform API.
  • Customer API client to platform API.
  • Network Server MQTT broker to mqtt-ingestion-worker.
  • Internal workers to database.
  • Internal services to message broker.
  • Admin users to platform data.
  • Tenant users to tenant data.

V1 starts with local username/password login for interactive users.

The authentication architecture must still support future OIDC-compatible identity providers and tenant-specific SSO, especially Microsoft Entra ID. The internal user, tenant, membership, and authorization model must not depend on a single authentication provider.

Long-term direction:

  • OIDC for interactive login.
  • Token-based API access.
  • Revocable scoped tokens.
  • Auditable authentication and token events.

Authorization is enforced by the platform API and workers.

Authorization must consider:

  • Platform role.
  • Tenant role.
  • Organization access.
  • Device access.
  • Export permissions.
  • Administrative permissions.

UI behavior must never be the only access control.

Tenant isolation is mandatory.

All tenant-owned data must be tenant-scoped.

Cross-tenant data leakage is a security defect.

Secrets must not be stored in source code.

Secrets must be provided through Kubernetes secrets or another documented secret mechanism.

Logs must not include:

  • Passwords.
  • Tokens.
  • Raw credentials.
  • App keys.
  • Secrets.
  • Unnecessary personal data.
  • Sensitive tenant data.

Audit logs are required for:

  • User changes.
  • Role changes.
  • Tenant changes.
  • Organization access changes.
  • Device assignment changes.
  • Decoder changes.
  • Export creation.
  • Security-relevant admin actions.
  • Token model.
  • Password storage if local users are implemented.
  • MFA requirements.
  • Service account model.
  • OIDC provider mapping and tenant-specific SSO rollout details.