The UniSentinel platform

One foundation under every module

License modules one at a time or all at once — they all stand on the same core: one login, one permission model, one audit trail, and one place for dashboards, reports, notifications and integrations.

SSO (OIDC) + TOTP 2FAPer-action RBACAppend-only audit trailCloud, Linux or Windows Server

Platform services

Built once, shared by every module

Every capability here is available to every module automatically — no duplicated settings, no parallel systems, no seams.

Identity, SSO & 2FA

Local accounts with password policy and lockout, TOTP two-factor authentication, and single sign-on via OIDC with just-in-time provisioning. Admins can list and revoke active sessions.

One login, one app drawer

An M365-style app drawer puts every licensed module a click away inside a single session. Unlicensed modules stay visible but greyed — you always see what the platform can grow into.

A shared approvals engine

Modules request approval for sensitive actions — risk acceptance, policy publication, audit report issuance. You set the rule per action: roles or named users, including N-of-M, with the full decision chain recorded.

Notifications, in-app and email

Domain events drive an in-app inbox and email via your SMTP server, with per-user preferences, per-event templates and an optional digest — deliveries are retried until they land.

Settings & branding

Upload your company logo once and it appears in the app shell, the login page and every report header and cover — alongside your brand colors. Each module plugs its settings panels into one settings tree.

Licensing & entitlements

Cloud entitlements, or an Ed25519-signed license file verified fully offline for self-hosted installs. Expiry means a grace period and then read-only mode — never a data lock-in.

Access control

An RBAC engine that treats every action as a permission

Permissions aren't four CRUD checkboxes. Every module declares a catalog of per-action permissions — named module.resource.action — and the platform enforces them the same way everywhere.

  • A generated permission catalog covers every action, including the ones beyond CRUD: approve, assign, publish, close, export.
  • Build custom roles in a role-builder UI — clone a preset and adjust it by module, resource or action — alongside system roles like Owner, Administrator and a read-only Auditor.
  • Every request is checked fresh against the database — the platform never trusts token claims. The UI hides what you can't do; the server re-checks regardless.
  • API tokens carry scopes from the same catalog, so humans and machines answer to one authorization model.
Role — Risk ManagerCustom role
risk.risks.viewRiskGranted
risk.risks.approveRiskGranted
risk.risks.deleteRiskDenied
catalog.assets.importCatalogGranted
platform.roles.managePlatformDenied

Accountability

An audit trail even the application can't rewrite

Every change in every module lands in one append-only audit log — who did what, to which entity, with the exact difference.

  • Each entry snapshots the actor's name and email at the moment of the action, so history stays legible even after people leave.
  • Append-only is enforced in the database itself: rewriting or deleting log entries is blocked at that level, and the application runs under a restricted database role with no right to alter the log.
  • Security events are first-class audit entries: role changes, SSO configuration changes and license uploads are all recorded.
  • Workspace-scoped, indexed and paginated from day one — built to be read by auditors, not just written.
Audit trailAppend-only
Role permissions updatedplatform.rolesSecurity
SSO configuration changedplatform.ssoSecurity
License file uploadedplatform.licenseSecurity
Risk acceptance approvedrisk.approveRecorded
Report exported (PDF)reports.exportRecorded

Insight

Dashboards and reports, fed by every module

Modules register their widgets and report types; the platform turns them into one insight layer.

A widget registry, not hard-coded charts

Each module's manifest registers its dashboard widgets, and every widget carries its own configuration form — filters, scope, chart type — so a new module brings new insight without any platform changes.

Your dashboards, your layout

Drag-and-resize grids give every user a personal home dashboard, alongside shared dashboards published to specific roles. Every module ships a sensible default dashboard on its landing page.

Widgets obey the viewer's permissions

Every widget's data runs under the permissions of the person viewing it — a shared dashboard can never leak a record the viewer couldn't open directly.

Branded, scheduled reports

Parameterized report templates carry your logo, cover and headers, run on demand or on a schedule, and export to PDF, XLSX and CSV.

Open by design

Connected to the tools you already run

One connector framework, one documented API, one webhook pipeline — all governed by the same permission model as everything else.

A connector framework

Scheduled connectors map external data into the right modules, with deduplication and per-connector sync logs. CSV import ships first — a day-one integration path for every customer — followed by vulnerability scanners and asset sources.

A REST API with real authorization

A versioned, OpenAPI-documented REST API with workspace-scoped tokens that carry permission scopes from the RBAC catalog — rate-limited and audit-logged like any other actor.

Webhooks you can trust

Subscribe to domain events and receive signed deliveries with automatic retries, so downstream systems can verify authenticity and never miss an event.

SSO and mail, standards-based

Single sign-on via OIDC and outbound email through your own SMTP server — the platform plugs into the identity and mail infrastructure you already operate.

Frequently asked questions

Does every module get these platform features?

Yes. Each module declares its permissions, widgets, report types, settings panels and events in a manifest, and the platform assembles the permission catalog, app drawer, dashboards and settings tree from those declarations — so every module, present or future, inherits the same foundation.

Can we build our own roles?

Yes. The role builder lists the entire permission catalog grouped by module, resource and action. Clone a preset role, adjust it down to the individual action, and assign it — with guardrails: system roles can't be edited, and you can never remove the last user who can manage roles.

Can auditors get read-only access?

Yes. A read-only Auditor role ships built in as a system role, and because every request is permission-checked fresh on the server, read-only means read-only — across the UI, reports and the API.

Does the API respect the same permissions as the UI?

Yes. API tokens carry permission scopes drawn from the same catalog that governs users, every call is checked on the server, and API activity is written to the same audit trail as any human actor.

Get started

See UniSentinel running on your terms

Book a 30-minute walkthrough. We'll map your program to the modules you need — cloud, on-prem Linux or Windows Server.

Every module works standalone. License only what you need — grow when you're ready.