§ Security
Security that supports a dependable assessment experience.
Before an assessment can begin, Safe Online Exam checks both barriers
A leaked or stale config file
Certificate encryption
Opens only on a device with the private identity.
Config Key proof
Passes only if the config matches current settings.
Access code released
Protects the file. Every .seb is wrapped to your public X.509 certificate (SEB pkhs). The private identity sits on approved managed devices — non-extractable where supported, and restricted to the SEB application.
Protects the code. The server re-verifies the Config Key hash against the assessment, the settings fingerprint, and the URL family before minting a single-use, two-minute proof token.
Controls
The controls behind the workflow
Each control keeps the Canvas-to-SEB handoff tied to the institution, assessment, and policy that authorized it. The details are explicit so security and IT teams can evaluate the model without guesswork.
Signed launches only
Every launch is validated for RS256 signature against the Canvas JWKS, plus issuer, audience, nonce, token age, timestamps, LTI version, message type, deployment ID, target URI, and the initiating browser's transaction cookie.
Replay closed atomically
LTI state is encrypted, valid for ten minutes, bound to a short-lived HttpOnly cookie, and claimed through an atomic PostgreSQL state claim. A replayed launch loses the race and is rejected.
Proof, not assertion
A code is released only after SEB proves its Config Key hash against current settings. A config from before a policy change cannot produce a valid proof — which is why stale files simply stop working.
Public material only, server-side
The service holds the public X.509 certificate and nothing more. The private identity belongs in your device-management platform, restricted to the approved SEB application.
A tool, not a Canvas proxy
Canvas calls are constrained to the configured origin and its /api/v1 base, with size limits and deadlines. Each person holds one durable grant scoped to the tool's own endpoints, and Canvas still enforces their real course permissions.
Admission control
Initiation and token validation run against process-local and PostgreSQL-backed budgets. Grant minting is rate-limited per principal and per IP — a valid launch is not a licence to mint configs in bulk.
Everything expires
Nothing sits around waiting to be reused
Grants, proofs, launch state, and sessions all carry a short lifetime. Transient records and operation locks carry an expires_at that a bounded cleanup job drains in batches.
Bars scaled for legibility, not to a linear time axis.
Key custody
Who holds what
The single most important line: the service never holds the private identity, and the managed tier does not change that.
The service
Holds
Public X.509 certificate, LTI signing key, Canvas OAuth credentials
Never
The private client identity, its .p12, or its passphrase
Your MDM / vault
Holds
The private identity and its protection material
Never
Broad instructor, student, or runtime access
The approved client
Holds
A non-extractable, SEB-restricted private identity
Never
An exportable identity reachable by a student account
Data residency
It is your database
Self-hosted or managed, the store is a PostgreSQL 17 database scoped to your deployment. There is no shared multi-tenant datastore, because there is no multi-tenancy.
| Table | Contents | Lifetime |
|---|---|---|
assessments | Discovery data and per-assessment SEB state | Durable |
courses | Defaults, setup state, exam-tool catalog | Durable |
canvas_oauth_tokens | One grant per numeric Canvas user ID | Per authorization |
admin_course_connections | Root-account course index and assessment counts | Durable |
admin_tool_presets | School tool presets and rollout state | Durable |
sessions | Session payloads under a hashed ID | 30-min lifetime |
transient_states | Replay claims, OAuth state, grants, proofs | Cleanup-drained |
operation_locks | Short assessment-update leases | Cleanup-drained |
Limits
What this does not do
A clear assessment-security plan includes its boundaries. These are the areas an institution must plan alongside Safe Online Exam.
Not device management
The setup check confirms the app's SEB integration. It does not establish device trust or replace a managed-device baseline. An unmanaged machine cannot offer the same non-extractability assurance.
Accommodations need a plan
Automatic Assessment Configuration on macOS may block third-party assistive tech. That accommodation needs a separately approved arrangement — not a weakened config shared with everyone.
Validate against real clients
SEB settings are honoured by the client, and coverage varies across releases and operating systems. Validate the full policy with a real supported client after SEB or OS updates.
One tenant, one deployment
Environments that must stay isolated need their own service, database, secrets, and Canvas registration. Mixing them is a failure mode, not a shortcut.
Want to review the model with your team?
Bring the questions from your Canvas, IT, and assessment stakeholders. We can walk through the operational model as part of a Safe Online Exam demo.