Provisioning
Administrators create or link accounts without opening anonymous public registration.
Security engineering guide
The foundations of a secure client portal
A login screen does not make a portal secure. The important controls sit in identity, authorization, tenant boundaries, publication rules and evidence when privileged actions occur.
- Tenant isolation
- Least privilege
- Auditable publication
Derive access from the authenticated account
A client should never choose an organization identifier and rely on the interface to hide other records. The API must resolve the permitted organization from the authenticated account and apply that boundary to every query.
- Deny access by default
- Check ownership server-side
- Use reduced client response models
- Test cross-organization access explicitly
Treat identity lifecycle as product functionality
Authentication
Strong password handling, rate limits, session controls and MFA protect more than the initial login.
Roles
Client, moderator and administrator permissions stay explicit and are enforced by the API.
Recovery
Revocable sessions and recovery procedures are designed before an account is compromised.
Draft internal data should not leak by accident
Proposals, milestones, support notes and monthly reports need an explicit client-visible or published state. Administrative changes should create audit evidence without writing credentials or sensitive payloads into logs.
- Published-state checks on every client response
- Internal notes excluded from client DTOs
- Immutable commercial snapshots where history matters
- Audited privileged changes and observable background jobs