Incident & Service Management Platform

The problem

Staff and students need help from eight service teams: ICT, facilities, security, transport, student affairs, procurement, finance and administration. Each request needs an owner, a deadline someone is accountable for, and a record of what happened to it.

The group was also building other internal apps, starting with procurement and an executive dashboard. Without a shared sign-in, each app would bring its own passwords, its own MFA and its own way of granting access. That's three times the attack surface, and no single place to check who can reach what.

So the work came in two parts: the service desk, then one sign-on service for all three apps.

Part 1: The service desk

A React front end on a Django REST API. Incidents ("something is broken") and service requests ("I need something") share one ticket model, so SLAs, assignment and reporting work the same for both.

What happens to a ticket

1. It's raised as an incident, or as a request from the service catalogue, with a priority and an impact scope from "just me" to "entire organisation". The service team comes from the catalogue item, not from whatever the browser sends.
2. Its SLA deadline is set from the policy for its priority.
3. It's assigned to the least-loaded member of that service team, who gets an email.
4. Every change to a field is recorded with who made it and when.
5. If it misses its deadline, a scheduled job emails about the breach once, and the service team can escalate it to admins.
6. Once resolved, only the requester can close it and rate it from 1 to 5, once. The database enforces the range.

Who sees what

Admins see everything. Service team members see only their own team's tickets. Staff and students see only tickets they raised. Internal notes are hidden from requesters, and service teams can't reach other teams' notes.

Approvals with separation of duties

Catalogue items that need approval start as pending. Requesters can't approve their own requests, service team members can't approve at all, and whoever approves a request can't also resolve it: a different agent has to. A request that's pending or rejected can't be resolved.

An insights dashboard reports volumes by priority and team, SLA performance, resolution times and average satisfaction.

Part 2: Single sign-on

A separate Django service is the only place where passwords, MFA secrets and sessions live. Apps never see a password. Each one checks tokens itself against the service's published public keys, so the sign-on service isn't called on every request.

Catching a stolen refresh token

Each refresh token works once. If a token that has already been used turns up again, someone has a copy, so every session for that user is ended. The check is a conditional update, so two requests racing with the same token can't both succeed.

# Conditional UPDATE so two concurrent refreshes can't both succeed.
if not RefreshToken.objects.filter(
    pk=rt.pk, revoked_at__isnull=True
).update(revoked_at=timezone.now()):
    revoke_all(rt.user)
    raise TokenReuse(rt.user)

Security and controls

These are the controls I would test as an IT auditor:

Decisions worth explaining

Testing

60 tests on the service desk cover SLA deadlines, least-loaded assignment, breach and escalation emails, who can see, close and rate which tickets, and every approval rule, including that an approver can't also resolve.

45 tests on the sign-on service cover cookie flags, origin checks, lockout, refresh-token reuse ending every session, the PKCE handoff, MFA enrolment, and checks of the authenticator-code algorithm against the standard's published test values. They also cover each step of the account approval chain, including that nobody can approve what they raised and that a failed email never loses the request.