Secure multi-role staff and client portal (architecture design)
Architecture for a single sign-in staff and client portal that protects staff records and client data by structure: server-side authorisation, layered client isolation, a separate HR permission and an append-only audit log.
Design, not built
Problem
An organisation ran reporting, project activity, company knowledge and internal forms across spreadsheets, email threads and separate tools. Leadership had no single live view of client health, and clients had no self-service view of their own results.
Goal
One application with single sign-in, a staff side and a later client side, on cloud infrastructure the company already used and at a small monthly running cost, with sensitive data protected by the structure of the system rather than by convention.
My role
Architect and team lead for a small team (design, web development, and me on the AI and data layer, the timeline and the security model). I wrote the scope and architecture specification, the approval deck and presenter notes, commissioned and reviewed the legal and regulatory research, and had the specification cross-reviewed twice by independent AI models.
Solution
A web API with a separate single-page front end, a managed relational database and serverless hosting. A nightly copy from the existing reporting warehouse feeds the dashboards, a role-scoped knowledge assistant answers from company knowledge, and a credential vault is protected by cloud key management. Everything is designed around server-side authorisation and hard isolation between clients, staff and sensitive HR data.
This is a design. Nothing described here is presented as built.
How it works
Sign-in. Staff sign in through the company identity provider with no portal password. An account is admitted only if it matches a record created in advance, verified against the provider's signed token and stable account id, and removal from the company directory ends access. Clients use in-app credentials.
Roles. Four roles, plus a separately granted HR permission that administrators cannot grant themselves.
Five rules for every screen. Authorise on the server for every request; remove sensitive columns in the query itself; deny by default; log every read and export of sensitive records (who, which record, which kind of field, never the value); and prove with automated tests that an employee cannot reach HR data and a client cannot reach another client's data or staff data.
Layered client isolation. Every client request is scoped from the session, never from an id the browser supplies. The sensitive HR data sits in a separate database area reachable only by credentials the client-facing code does not hold. The client side runs as its own deployment with its own identity, and row-level filtering constrains queries even if application code is wrong. Backups and database administration count as HR data access.
Audit. An append-only audit log, enforced by database permissions and mirrored to the cloud provider's logging, records refusals as well as successful access.
Reporting. Reporting pages read only the application database, fed nightly from the warehouse. Project activity is pulled per project, because the project tool's account-wide feed leaves out completed work.
Portability. Names, paths and storage are configuration, so a second deployment is not a rewrite.
Technical challenges
Client isolation that survives a bug in application code.
Separating "runs the system" from "sees everyone's HR records".
Deciding, after legal and regulatory research, which sensitive HR fields to hold at all: the necessary ones held encrypted with every reveal logged, and the most sensitive identifiers kept out entirely.
An audit log that resists someone who has database access.
A reporting source that cannot push changes, so the design has to pull.
Keeping the audit log out of the knowledge assistant's reach, and the assistant scoped by role.
Keeping the running cost well under budget.
Capabilities
- Staff single sign-on and client logins
- Role and permission model with a separate HR permission
- Client hub with health measures
- Leadership dashboards and a report centre
- Staff directory
- Knowledge library with a cited-answer assistant
- Credential vault
- Admin console
- Immutable access log
Technology
Impact
Design stage: a written architecture and approval deck, corrected through two independent review rounds, with regulatory questions researched before any sensitive table exists. No build or usage outcomes are claimed.
Skills demonstrated
- Security architecture and threat modelling
- Multi-tenant isolation
- Privacy by design for HR data
- Identity integration
- Data pipeline design
- Cost planning
- Team leadership
- Executive communication