Issues
Create, read, write, update, delete, assign, transfer, and comment.
Security and access
The project source shows a detailed access model, explicit security boundaries, MFA controls, audit logging, encryption for protected secrets, and narrow integration authentication.
RBAC model
Kantan Desk uses role-based permissions for staff controls and ticket-specific ownership checks for requester access.
| SuperAdmin | Can bypass permission checks and is required for creating inbound API keys. |
|---|---|
| Admin | Receives the full effective permission list in the application’s role resolver. |
| Role-based staff | Receives the union of assigned role permissions when roles are active. |
| Roles inactive fallback | When RBAC is not in use, protected routes require elevated access rather than open access. |
| Team members | Can be grouped into teams with admin/member responsibilities and scoped ticket, mailbox, webhook, tag, and client access. |
| External requesters | Do not require staff RBAC roles to view or reply to their own tickets; route-level ownership checks authorize their ticket access. |
Fine-grained permissions
The project defines explicit permission groups for support work, administration, integrations, observability, privacy, storage, and AI assistance.
Multi-factor authentication
Kantan Desk supports voluntary MFA, admin-required MFA, reset workflows, backup codes, and audit events.
Production requires separate base64 secrets for JWT signing (SECRET) and stored-data encryption (DATA_ENCRYPTION_SECRET).
Protected stored credentials and integration secrets use authenticated AES-256-GCM encryption where the application must recover the original value.
Passwords, API keys, and verification material use one-way hashing where Kantan Desk does not need to recover the original value.
Full sessions are backed by database session rows, with hardened binding controls available for deployment-level protection.
Production requires explicit CORS origins, and wildcard origins are rejected in production.
PostgreSQL, Redis persistence, uploaded files, and encryption secrets all matter. Losing DATA_ENCRYPTION_SECRET can make encrypted integration credentials unrecoverable.
Admins can configure an OIDC provider for staff login. Kantan Desk acts as a relying party; session creation follows the same audit-logged flow as password login.
Each audit log row stores a SHA-256 chain hash linking it to its predecessor. Deletions, modifications, or reorderings break the chain and are detectable. Chain integrity is maintained continuously; a SuperAdmin endpoint can walk the complete chain and surface the first point of divergence.
Password reset codes are SHA-256 hashed before storage. The plaintext code is never written to the database; only the hash is compared on submission.
Login attempts are subject to layered rate limiting and timing protections covering both IP and account dimensions. Unknown-user paths are designed to produce equivalent response characteristics to valid-user paths to reduce information leakage.
Audit trail in practice
Audit entries capture the event, actor email, target, risk level, and a SHA-256 hash linking each row to its predecessor. A broken chain is detectable without relying on log access controls alone.
| Event | Actor | Risk | Chain hash |
|---|---|---|---|
| LOGIN_SUCCESS | [email protected] | low | a3f82c… |
| CLIENT_CREATED | [email protected] | low | 7de419… |
| SSO_PROVIDER_UPDATED | [email protected] | high | 2bc06e… |
Accurate boundary
Kantan Desk is designed for private support operations, but the server must be able to read ticket content to provide ticketing, search, email, portal, automation, and administrative workflows. MFA applies to user login sessions; API keys and webhooks are authenticated separately through HMAC signatures and IP allowlists.