Authorization Management

Who can access which system, who approved it, and when was it revoked — this is the question that decides, in minutes, whether an audit finds a control or paperwork. The application tracks every step from the request through the periodic review to the revocation in a sealed, independently verifiable record.

Version

1.0.0

Platform

ASP.NET Core 10, MongoDB 6+ — Windows Server or Linux

Type

Web application, self-hosted deployment

Distribution

Licensed, activated through the License Management service

Price

Custom quote

NIS2 Article 21(2) requires access control policies, periodic reviews, offboarding and multi-factor authentication — in many organisations this still lives in shared spreadsheets and e-mails, where an audit six months later cannot say who let a given user into a system.

The register runs the same process in a MongoDB-backed database: every request, approval, review and revocation is a traceable event, closed with an HMAC seal. The seal proves that a row was actually written by the application — direct database access is not enough to grant yourself an entitlement.

• Two matrices, two questions

  The access matrix shows who can use what; the device matrix shows who is responsible for it. Both are filterable, printable and export to Excel with the same layout — the artefact an audit actually asks for.

• Termination tasks

  A revoked entitlement can open a task through six paths (manual revoke, expiry, failed review, offboarding, account archival, device retirement) for the device owner, the only person who can act. Closing a task is always a human decision, and it is recorded in the audit log.

• Requesting on someone else's behalf

  The key-user role can submit a request for staff in their own area — a colleague with an account, or a name from the HR directory — but cannot decide or revoke: requesting and approving stay two separate jobs.

• Sealed, tamper-evident audit log

  Gap-free sequence numbers and an HMAC-SHA512 seal on every row, carrying the source IP. The integrity check button recomputes both and shows exactly which row was altered after the fact.

• Mandatory two-factor authentication

  MFA is a global, admin-controlled policy with TOTP replay protection. Turning it on sends everyone — including the admin — to the enrolment page until they register an authenticator.

• Field-level encryption and key rotation

  Names, e-mail addresses and TOTP secrets are encrypted at rest with AES-256-GCM. Rotating the field-encryption key on the Encryption Keys page re-encrypts every row immediately — the audit-integrity key deliberately does not.

• IP blocking and account recovery

  Failed sign-in attempts trip an automatic IP block based on a threshold and time window; clicking an address in the log brings up everything that happened from it.

An ASP.NET Core MVC web application on .NET 10 with a Bootstrap UI, split across five projects: Domain, Application, Infrastructure, WebCore (session wiring) and Web. The data layer is MongoDB, with its own MongoDB-backed Identity store and TOTP replay protection.

The encryption and audit-integrity keys live in a key store protected by DPAPI (Windows) or an encrypted volume (Linux), and session cookies are protected by the Data Protection API. Outgoing mail runs on MailKit, and the installation authenticates itself against the License Management service every six hours and on every sign-in.

C# .NET 10 ASP.NET Core MVC Bootstrap MongoDB MailKit AES-256-GCM HMAC-SHA512 TOTP