Roles and permission model

A user has an account. A role is a named set of permissions: read, write, approve, export, grant administration. A permission is checked at the boundary: screen, action or data scope (own records, a department, the whole set — by the process). One person may hold several roles when the model says so. A role is not an opinion in a spreadsheet: the system refuses an operation the role does not have. The dictionary of roles and permissions is set before build; the next role or a new data scope is a later stage.

Dedicated to one solution

The first scope covers one application and one permission model. Screens, actions and data come from that process — not from a catalogue of universal rules. A second application, a second model or a shared role catalogue for many systems do not enter the first stage. Integration with an existing company account directory is possible when that directory is in the quote and has a described contract. The identity-scope decision is made in the quote, not as a default service.

Grant administration panel

A panel for a named administrative role enters when it is in scope: account list, grant and revoke a role, a view of current permissions. An access request and approval — when the process requires it. The administrator sees who holds which role; they do not see operational data outside the agreed scope. The panel does not replace the application to which access is granted. Without a panel, grants go through an agreed channel (API or import) — that is a separate decision in the quote.

API to the application

The agreed application calls the access layer through an API: who the user is, which roles they hold, whether a named action is allowed, what the data scope is. The answer returns in the same session. The contract describes the check type, the account id, the permission code and the result. Session and token are part of the software — issue, refresh, expiry and revoke. Each check has a limit and a log. The database — PostgreSQL, MSSQL or MariaDB, by the application's stack — holds accounts, roles, grants and the trail. TensorFrog does not issue tokens as a separate service outside that application.

Audit of grants and revocations

A role change, a grant, a revocation, a session start and a failed permission check leave a trail: who, to whom, which role or permission, when, from which source. The administrator sees the grant history. An auditor — when that role is in the model — sees the same register without the right to change it. Log retention follows an agreed policy. This is a trail in software the organisation maintains — it does not replace a legal procedure or a state register.

First stage

One application, one permission model, a quote before build. Accounts, two or three roles, a check on agreed screens and actions, session and token, a trail of grant and revocation. An administrator grant panel — when it is in that quote. After sign-off: further roles, a data scope, an access request, a second application or an import from an existing account directory — each with its own quote.

Authorisation system — users, roles and access to an application

What this system is

How we will judge the effect