Security & Identity

Identity, access and audit

Seven authentication methods that run side by side, SSO group-to-role mapping, TOTP MFA, SCIM 2.0 provisioning, AES-256-GCM field encryption and an audit trail you can stream to your own SIEM. All of it included, none of it a tier.

Built in

Included at every tier, on every deployment

  • Azure AD / Entra ID, Google Workspace, LDAP / AD, local accounts
  • SCIM 2.0 provisioning with per-provider bearer tokens
  • TOTP multi-factor with recovery codes
  • AES-256-GCM encryption of stored secrets
  • Full audit log with CSV and JSON export
  • Audit forwarding to HTTP or RFC 5424 syslog sinks
You configure

Decisions that belong to your organisation

  • Which providers are enabled, and their order on the login page
  • Whether a provider auto-provisions, and at which default role
  • Allowed email domains per provider
  • Group-to-role mappings per provider
  • Session limits, token lifetimes and rate-limit windows
  • Which categories and event types reach each audit sink
Not claimed

Absences we would rather you hear from us

  • No SAML runtime — the provider type exists in configuration only
  • No user impersonation, by design
  • No personal access tokens — only MCP and SCIM credentials
  • No permission schemes — access is roles plus grants
  • No compliance certification held by Trakr
Method
Included Trakr Self-hosted · Belgium
How it works Mechanism
Local accounts (BASIC)
Included
BCrypt · sign in by username or email · tenant-scoped
Azure AD / Entra ID
Included
OAuth2 / OIDC · tenant-specific endpoints · groups claim · Graph userinfo
Google Workspace
Included
OAuth2 / OIDC
LDAP / Active Directory
Included
JNDI · search-then-bind · ldaps:// · configurable user and group filters
SCIM-provisioned accounts
Included
Marker on accounts created by your directory
Helpdesk guest (passwordless)
Included
Six-digit emailed access code exchanged for a portal session token
MCP API key
Included
Bearer trakr_mcp_* granting ROLE_MCP · scope comes from the key alone
SCIM bearer token
Included
One per auth provider · ROLE_SCIM · constant-time comparison
SAML
No runtime handler
An accepted configuration value with nothing behind it
Legend Implemented Not implemented
01 / Providers

Per-provider provisioning, per-provider limits

Authentication providers are configured per organisation. Each can be enabled or disabled on its own, carries a display name, and takes a position in the ordering shown on the login page — so the provider your staff actually use sits first, and the fallback sits last.

Each provider then carries its own policy: a just-in-time auto-provisioning toggle, the default role a provisioned user receives, an allowed email domain allow-list, a connection test, and its own group-to-role mappings. Client secrets and LDAP bind passwords are AES-256-GCM encrypted, masked in API responses, and preserved on edit when the field is left blank — so saving a form does not silently blank a secret.

02 / Roles from groups

Highest rank wins, deterministically

A mapping ties an external group — an Azure AD object ID, an LDAP group DN — to a Trakr role, and is unique per provider and group. Someone who belongs to four mapped groups does not get an arbitrary answer: the highest rank wins, in the order ADMIN, MANAGER, MEMBER, VIEWER.

If no mapping matches, resolution falls back to the provider's default role, and then to MEMBER. Three steps, no surprises, and the same answer on every sign-in.

03 / MFA

TOTP, with the replay holes closed

Standard TOTP as specified in RFC 6238: six digits, a thirty-second step, one step of drift either way, a 32-byte Base32 secret and an otpauth:// URI with a configurable issuer. The digest algorithm is selectable between SHA1, SHA256 and SHA512, and the secret is encrypted at rest.

The details that matter are the ones around it. Used codes are cached for ninety seconds so a captured code cannot be replayed inside its own window. The MFA challenge token is single-use and held in a store that burns it after five failed attempts, with a ten-minute lifetime. Enabling runs setup, verify, then enable; disabling requires the password. Recovery codes can be copied and regenerated.

04 / Passwords

Twelve characters, and a breach check that fails open

Minimum twelve characters with upper case, lower case, a digit and a special character, plus a roughly forty-five entry blocklist of the passwords that always show up first in a spray.

On top of that, a HaveIBeenPwned k-anonymity check: only a SHA-1 prefix leaves the building, the request is padded, and it times out after three seconds. It fails open — if the breach service is unreachable, your users can still change their password. A security control that locks out your own staff during someone else's outage is not a security control.

Reset tokens are 32 random bytes, stored as a SHA-256 hash, single-use, consumed atomically so the same token cannot be redeemed twice, expiring after a configurable interval that defaults to an hour, delivered by branded templated email and cleaned up daily.

The sign-in path, step by step

Trakr issues a JWT signed with HMAC-SHA256 and carries it in a cookie named jwt_token — HttpOnly, Secure, SameSite=Strict. There are three token types: access, refresh, and a dedicated MFA challenge token.

  1. Rate limit first. Sign-in attempts are counted per IP address (20 by default) and per username (10 by default) in a fifteen-minute window, both configurable. A success resets only the per-user counter — the per-IP budget keeps counting, which is what makes it a credential-stuffing defence rather than a formality. The same limiter guards /api/mcp.
  2. Credentials, then the second factor. Local accounts verify against BCrypt; SSO providers complete their OAuth2 / OIDC or LDAP flow. Where MFA is enabled, an MFA challenge token is minted, and it is single-use and burned after five failures.
  3. A session row is created. Stored as a SHA-256 hash of the token alongside the IP and user-agent. Sessions are revocable individually or all at once, and a per-user cap — five by default — evicts the oldest first rather than refusing the new sign-in. A Caffeine cache holds validity; an hourly job clears the debris.
  4. Claims travel with the token. User, organisation, tenant, role, display name, requiresContextSelection and rememberMe. Remember-me carries a separate lifetime that survives refresh, renewal and context switches.
  5. Refresh rotates, once. Refresh tokens are hashed and one-time-use: presenting one mints a new pair and retires the old. Logging out everywhere, changing a password or completing a reset revokes them in bulk.
  6. Renewal slides, it does not cliff. Past a configurable fraction of the token lifetime the session renews, with a grace window rather than a hard revoke, so a user mid-form does not get thrown out.
  7. The process refuses to start misconfigured. Startup guards reject a JWT secret shorter than 64 characters, and reject the shipped development secret outright outside development mode. You cannot accidentally run production on the example key.
Control
Always on Trakr Every deployment
What it stops Behaviour
API CSRF header requirement
Enforced
State-changing /api/** calls riding an ambient cookie must carry X-Requested-With or Authorization
Per-request CSP nonce
Enforced
A fresh script nonce per request, strict script-src, frame-ancestors 'none'
Cross-organisation access guard
Fail-closed
IDOR by guessed identifier across organisations — denied unless explicitly permitted
HTML sanitisation of user rich text
Safelist
Stored XSS through descriptions, comments and portal submissions
SSRF guard on webhooks
Save + delivery
Non-HTTP(S) schemes and hosts resolving to loopback, private, link-local, CGNAT, IPv6 ULA or multicast
AES-256-GCM field encryption
At rest
OAuth client secrets, LDAP bind passwords, SMTP credentials, MFA secrets, integration tokens
Note The SSRF guard runs twice — once when a webhook URL is saved, and again at delivery, because DNS can change in between
Role
Rank Trakr Highest wins on conflict
Reach What it can see
SUPERADMIN
6
Cross-organisation super administrator
ADMIN
5
Organisation administrator
MANAGER
4
Team and project manager
MEMBER
3
Standard member with organisation-wide access
VIEWER
2
Read-only, organisation-wide
CONTRIBUTOR
1
Explicit project grants only
CUSTOMER
0
External · explicit project grants only
Role sets MANAGEMENT = SUPERADMIN, ADMIN, MANAGER FULL_ACCESS adds MEMBER PROJECT_MANAGEMENT gates SLAs, canned responses and ticket templates PROJECT_SCOPED = CONTRIBUTOR, CUSTOMER
Rank 1 / CONTRIBUTOR

Restricted internal contributor

A CONTRIBUTOR reaches only the projects they have been explicitly granted. Inside those projects they may create tickets, and edit and comment on tickets assigned to them.

They cannot change status, cannot reassign, cannot delete and cannot move a ticket between projects. It is the role for a subcontractor, an intern or a partner engineer who should be able to do the work without being able to reshape the board.

Rank 0 / CUSTOMER

External customer

A CUSTOMER is an external account with explicit project grants only. There is no organisation-wide reach to fall back on, and customers are never enrolled as project subscribers, so a project-wide watch never leaks internal traffic to an external account.

A second axis sits alongside the role: staff type, one of INTERNAL, CONTRACTOR or CUSTOMER, with per-organisation badge colours — so who someone is stays visible in the interface, not just what they can press.

Groups

Grants that survive turnover

Groups are organisation-scoped, named, described and given a hex badge colour. Membership records who added whom and when.

Project group access grants a whole group access to a project at a project-level role, and a group's project list can be bulk-replaced in one operation with organisation-boundary validation on every entry. Onboarding becomes a group membership rather than a tour of every project's member list.

Offboarding

Deleting a user without orphaning their work

Deleting an account requires an explicit answer for the tickets attached to it: UNASSIGN, KEEP as an anonymised tombstone, PROJECT_DEFAULT to hand each ticket to its project's default assignee, or reassignment to a named replacement — with an impact preview before you commit.

Anonymisation wipes credentials, the MFA secret, the avatar and the external identity, revokes sessions, and leaves references resolvable so history does not develop holes.

Supported

What the discovery endpoints report, and what actually works
  • Discovery ServiceProviderConfig, Schemas, Schemas/{id}, ResourceTypes
  • Users list, read, create, replace (PUT), patch
  • Delete Soft — deactivates the account
  • PATCH Supported
  • Filter Yes, maxResults 100
  • Auth scheme oauthbearertoken
  • Pagination startIndex / count
  • Groups Read-only, role-projected
PATCH paths handled: active, displayName, userName, externalId, name.*, emails, emails[type eq "work"].value, emails[primary eq true].value, plus a pathless replace.

Not supported

Advertised as unsupported rather than quietly ignored
  • Bulk operations No
  • changePassword No
  • Sort No
  • ETag No
  • Filter operators Parsed: eq ne co sw ew gt ge lt le
  • Honoured eq only
  • Group writes No — groups are projected from roles
  • Hard delete No — deletion deactivates
Group resources are projected from the four organisation roles — ADMIN, MANAGER, MEMBER and VIEWER — with member lists built from active organisation users. Your directory sees groups it recognises; it just cannot write to them. Bearer tokens are generated, checked and disabled from the auth-provider admin page.
01 / Vocabulary

The full action list, not a sample

Login success and failure, logout, session expired and revoked, MFA enabled and disabled, MFA challenge success and failure, password changed, password reset requested and completed, access denied, permission granted and revoked, role changed, user created, updated, deleted, activated and deactivated, project created, updated, archived and deleted, system startup and shutdown, garbage collection, scheduled task, configuration changed, log cleared, suspicious activity, rate limit exceeded, invalid token, API key created and revoked, data export, data import, and bulk operation.

02 / Categories

Eight categories to filter on

Every action lands in one of eight categories: authentication, authorisation, user management, project management, system, data access, security and configuration.

The categories are what make forwarding useful — a sink can take security and authentication only, and leave the routine configuration churn out of your SIEM ingest bill.

03 / Export

CSV and JSON, streamed

Both formats stream page by page with a row ceiling, so exporting a year of audit history does not try to build the whole thing in memory first. CSV carries a header row.

The export filter mirrors the list page field for field — what you see on screen is what leaves in the file, with no second, subtly different filter model to reconcile.

04 / Forwarding

HTTP with HMAC, or RFC 5424 syslog

An HTTP sink posts one JSON event per request, with an encrypted auth header and an HMAC signing secret so the receiver can verify the payload came from your Trakr and not from someone who guessed the URL. A SYSLOG sink speaks RFC 5424 over UDP or TCP, facility 13 by default, with a configurable app-name.

Each sink carries its own filters — allowed categories, allowed event types, only-failures — and its own health on the row: last attempt, last success, last status, last error, consecutive failures, delivered count and failed count. You can list, create, update, enable, disable, delete, and send a test event whose outcome is recorded like any other.

Dispatch is deduplicated per transaction and fires after commit, with the originating IP attached. An event that was rolled back is never forwarded, and an event that committed is forwarded exactly once.

The gaps, stated plainly

SAML has no runtime handler. SAML is an accepted provider-type value in configuration and nothing more. There is no assertion consumer, no metadata endpoint and no signature validation behind it. If your identity provider only speaks SAML, Trakr does not federate with it today — OIDC against Azure AD / Entra ID or Google Workspace, or LDAP against Active Directory, are the supported paths.

There is no user impersonation. A superadmin administers an organisation through the normal settings pages using an acting-organisation header, with a banner showing it is active — but never as a named person. This is a deliberate choice: it costs a support convenience and buys an audit trail in which every action has one unambiguous actor.

There are no personal access tokens. The only machine credentials are MCP API keys — SHA-256 stored, shown in plaintext exactly once, carrying a twenty-character display prefix, revocable, with lastUsedAt tracked — and SCIM bearer tokens, one per authentication provider, compared in constant time. A user cannot mint a long-lived token that carries their own identity.

Trakr holds no compliance certification. Not ISO 27001, not SOC 2, and we will not imply otherwise with a badge or a "designed to be compliant" phrase. What Trakr offers instead is structural: self-hosting. The application, the PostgreSQL database, the attachment files and the audit trail all live on infrastructure you run, in a jurisdiction you chose, inside your certification scope rather than ours. The theme even ships self-hosted webfonts so the browser makes no external font request. Certification is a question about a vendor's premises; self-hosting removes the premises from the question.

Can Trakr run more than one identity provider at the same time?

Yes. Authentication providers are configured per organisation, each one can be enabled or disabled independently, each has a display name, and they are ordered on the login page. Local BCrypt accounts, Azure AD / Entra ID, Google Workspace and LDAP / Active Directory can all be live simultaneously, each with its own just-in-time provisioning toggle, default role, allowed email domain allow-list and group-to-role mappings.

Does Trakr support SAML?

No. SAML is an accepted provider-type value in configuration, but there is no runtime handler behind it. If your identity provider must speak SAML, Trakr is not the right fit today. Azure AD / Entra ID and Google Workspace are supported over OAuth2 / OIDC, and LDAP / Active Directory over JNDI with search-then-bind.

How does Trakr map identity provider groups to permissions?

Each authentication provider carries its own group-to-role mappings: an external group identifier — an Azure AD object ID or an LDAP group DN — maps to a Trakr role, unique per provider and group. When a user belongs to several mapped groups the highest rank wins, in the order ADMIN, MANAGER, MEMBER, VIEWER. If nothing matches, the provider's default role applies, and failing that, MEMBER.

Can Trakr forward its audit log to a SIEM?

Yes. Audit sinks come in two types: HTTP, which posts one JSON event per request with an encrypted auth header and an HMAC signing secret, and SYSLOG, which speaks RFC 5424 over UDP or TCP with a configurable facility and app-name. Each sink has its own filters — allowed categories, allowed event types, only-failures — plus health counters on the row and a test event. Dispatch is deduplicated per transaction and fires after commit, so an event is forwarded exactly once.

What does Trakr do about credential stuffing and brute force?

Sign-in attempts are rate limited per IP address (20 by default) and per username (10 by default) inside a fifteen-minute window, all configurable, and the same limiter is applied to the MCP endpoint. A successful sign-in resets only the per-user counter, so an attacker spraying many usernames from one address does not get their IP budget refunded by a lucky hit.

Is Trakr certified against ISO 27001 or SOC 2?

No. Trakr holds no compliance certification, and we will not imply one. What Trakr gives you instead is self-hosting: the application, the PostgreSQL database, the attachments and the audit trail all sit on infrastructure you control, inside your own jurisdiction, under your own certification scope rather than ours.

Put the data inside your own perimeter

SSO, MFA, SCIM, field encryption and SIEM forwarding are included at every tier. Self-hosting is what makes them yours.