User Management & RBAC decides who can see a finding, who can approve a patch that runs on a production server, and whose session is still valid right now. Every account, role, permission flag and token in SITEY is issued, scoped and revoked here, inside your own deployment, against your own database.
The problem
A vulnerability platform holds the most useful internal document an attacker could ask for: a ranked, current list of everything broken in your estate, with the hostnames.
Most teams still run it on a shared administrator login, because splitting access properly is tedious.
The cost shows up in ordinary weeks. A contractor hired for a two-week engagement can read the whole backlog. A technician who should only close tickets can reach scanner credentials. Somebody leaves, the account is disabled, and the session they left open keeps working until the token expires by itself. When an auditor asks who approved the patch that took the billing server down, the answer is a name in a chat thread.
How it works
- Accounts are created by an administrator, never self-registered
There is no public sign-up path. Account creation requires an administrator session, and the role comes from a fixed list of six: admin, pentester_external, pentester_internal, reporter, teknisyen and user. A role outside that list is downgraded to the lowest one rather than accepted. Passwords are stored as bcrypt hashes.
adminpentester_externalpentester_internalreporterteknisyenuser - Every request carries a typed, revocable token
Login issues a short-lived access token (60 minutes by default) and a longer refresh token (7 days by default), both configurable at deployment. Protected endpoints accept access tokens only: a refresh token presented as a bearer credential, or a token with a missing or unrecognised type, is rejected rather than trusted. Logout adds the token’s unique id to a revocation list and can revoke the matching refresh token in the same call, after checking that it belongs to the caller.
- Deactivating an account ends the session in flight
The active flag is checked on every authenticated request, not only at login, so switching a user to inactive stops their next API call instead of waiting for the token to expire. Failed logins are counted per source IP; five failures inside fifteen minutes return HTTP 429 until the window passes.
- Role checks live in the endpoint signature, not the endpoint body
Authorization is a reusable dependency rather than a check copied by hand into each handler, which is how bulk endpoints historically ended up less protected than their single-item siblings. Two named gates carry the highest-risk decisions: patch approval and execution, and writes to scanner credentials and agent group membership. Both resolve to the administrator role in the current release, and each is declared in a single place, so widening them to another role is a one-line change rather than an audit of every handler. The same dependency is used across patch management, autonomous operations, the AI assistant, integrations, group management and agent updates, with regression tests around it. The interface reads the same role source, so restricted pages and sidebar entries stay hidden and fail closed without a valid token.
- Secrets never enter a user response
User records are serialised through an explicit field allowlist. Password hashes and the encrypted AI provider key sit outside it, so a sensitive column added later is excluded by default rather than leaked by default. The sort parameter is limited to the same allowlist, so the list cannot be ordered by a hidden column to read it.
What you can do
Create, edit, deactivate and delete accounts, with guards that stop an administrator deleting their own account or removing the last remaining administrator.
Give an external pentester an account whose reach is limited to manual findings recorded under their own user id, enforced on the list, the paginated list, statistics, the archived list, archive and unarchive, status changes and the bulk delete and bulk false-positive endpoints alike, not only on the main list view.
Search and filter users by name, e-mail, role and active state. The user API additionally supports server-side pagination and sorting, with the sort field restricted to the same allowlist that shapes the response.
Reset another user’s password as an administrator, or let users change their own against a policy: eight characters minimum, with upper case, lower case and a digit, checked against the current one and required to differ from it.
Read a per-user activity history of logins, logouts, profile changes, password changes, account creation and deletion. Administrators see any user’s history; users always see their own.
Narrow what an account sees with permission flags carried inside the session token. The vulnerability flag is enforced on the server, so a restricted account gets an empty list back from the API itself.
Record a workforce profile on each account: department, manager, seniority, specialisation, priority ceiling, preferred work types and location. Assignment suggestions rank people by seniority, open workload and completed tasks, and show department and specialisation alongside each candidate. Preferred work types and location are stored on the profile but do not feed that ranking today.
Keep the AI provider key under administrator control only and encrypted at rest, alongside system-wide SMTP and IMAP settings whose passwords are stored encrypted and returned masked.
The agent and attack-surface permission flags currently control only what the interface displays, not what the API returns, so treat those two as a view preference rather than a server-side boundary.
Who it is for
CISOs who must show that patch approval is restricted to administrator accounts and recorded. SOC and vulnerability analysts who want a scoped view instead of a shared admin login. System administrators, for whom account lifecycle should be a two-minute task. Compliance officers who need an account and activity record for access reviews. Consultancies and external pentesters who need an account that cannot reach anything outside their own records.
Why it matters
Least privilege only counts if it is enforced where the decision is made. In SITEY the sensitive actions are not read-only reports: the platform runs remediation scripts on production machines and holds credentials for your scanners. Putting those behind named gates, with the check in the endpoint signature and a test around it, is the difference between an access model and an access diagram.
The payoff is offboarding that works, a contractor account you can hand over without a side agreement, and a record of account and password changes you can produce during an audit rather than reconstruct from memory.
Works with
- Approval gates: the roles defined here decide who may pass a patch or remediation gate.
- Team workflow: accounts, roles and current open workload from user management drive the assignment suggestions on the team board.
- Task management: tasks are owned and edited under the same role and ownership rules.
- Compliance mapping: findings are assessed against framework references such as OWASP Top 10, PCI DSS, ISO 27001 and NIST. For access reviews, the evidence this module produces is the per-user activity history described above.
Frequently asked questions
Can SITEY authenticate against Active Directory, LDAP or SAML SSO?
Not today. Accounts are local to your SITEY deployment, with bcrypt password storage, IP-based lockout and per-user activity history. If a corporate identity provider is a hard requirement, raise it before you buy rather than after.
Are roles or the permission checkboxes authoritative?
Roles. The server-side gates for patch approval, integration credentials, agent group writes and user management are all decided by role. The permission flags travel in the session token; the vulnerability flag is enforced on the server as well, while the agent and attack-surface flags currently only hide the corresponding views in the interface. Treat the flags as a narrowing on top of a role, never as a replacement for one.
What happens to an open session when we disable an account?
It stops on the next request. The active flag is verified on every authenticated call, so there is no window in which a disabled account keeps working until its token expires. Logging out revokes the access token and, when the client sends it, the refresh token too.
Can we give a contractor an account without exposing the whole backlog?
Yes, that is what the external pentester role is for. Such an account is limited to manual findings recorded under its own user id, is blocked from user management, and the same restriction applies on the bulk endpoints, which is where scoping usually leaks. One caveat worth knowing before you plan an engagement around it: in the current release this role cannot create manual findings itself, so agree the intake path with us first.
Access control is the part of a security platform buyers discover is missing at the worst moment. To check ours against your own offboarding and audit requirements, see the pricing page. One licence covers a deployment you run on your own servers, and your scan data stays in your own database.