Exam Manager for IT and security reviewers

The mechanisms, described precisely

StudyDrome Exam Manager isolates each institution by account id, in two layers. A base class refuses to build a record without one. And a database filter on every tenant-owned table holds even when a query omits its own. This page describes that mechanism, and the access, session, audit and file controls around it.

Book a pilot

How are institutions isolated from each other?

Every institution is a tenant. An account id is carried on every record it owns.

Isolation runs in two layers, and the architecture names them that way.

First, aggregate roots inherit a base class. It refuses to build a record without a valid account id, so an unattached record cannot exist.

Second, each module's data context adds a global filter to every tenant-owned table. A repository method that omits its own filter still cannot read another tenant's rows.

The tenant is resolved once per request, from the signed request itself. It is never taken from request input.

A validator then runs before any endpoint. It confirms that the tenant is active. That the domain belongs to it. That the client address is permitted. And that the token's own tenant claim matches the tenant that was resolved.

The address check is fail-closed. An address that cannot be parsed is refused, not allowed.

Departmental separation rides on top. A sub-account scope is honoured in two cases only: the caller is an account administrator, or that sub-account appears in their own token.

What this is, precisely: a shared database with a shared schema. It is isolated by account id, at the application and data layers. Isolation reviews are recorded per module, against each milestone.

How is access controlled?

Permissions are granular and declarative. Each endpoint declares the single permission it requires, rather than checking a role name.

That granularity is the point. An exam office holds invigilation rights without authoring rights. A psychometrician reads violation data, but cannot end an attempt. Publishing, grading, results export, results viewing and question import are each a separate code.

Isolation is enforced at the data layer, independently of permissions. A misconfigured role cannot reach across tenants.

How do staff sign in, and how are sessions ended?

Institutions can bring their own identity provider. StudyDrome supports per-tenant OpenID Connect. Google, Microsoft, Okta and generic providers are all supported.

Two provisioning modes are available. Just-in-time creates a recognised user on first sign-in. Pre-provisioned-only requires the account to exist already.

Sessions are token-based. A short-lived access token is paired with a refresh token held server-side, never in the browser alone.

Refreshing rotates both. It issues a new access token and a new refresh token. It marks the old refresh row revoked, with a pointer to its successor. And it adds the previous access token to a shared revocation list.

That list is checked on every authenticated request, in every host. Revocation is an action, not a wait for expiry.

Users can list their own active sessions. Each shows its address, browser and start time. They can end any of them.

An administrator with the sessions permission can end every session for a user. That is written to the activity log.

Deactivating an account locks it out and revokes every session it holds, in one step.

What controls apply during an exam?

Exam delivery carries its own layers. Each is set per exam, and each works on its own.

Control

Mechanism

Access codes

Shared across a cohort, or unique per candidate. Held at test level, so republishing never forces redistribution

Address restriction

An allow-list accepting single addresses and ranges, checked when a candidate prepares, starts and resumes. Fails closed on an address it cannot parse

Device binding

An attempt can be tied to the browser profile it began on, checked on resume, with an invigilator able to release the binding when hardware fails

Academic holds

A hold carrying the exam-access restriction is checked before any code or address rule, at every point an exam can be reached, and fails closed on a lookup error

Attempt limits

Counted across every publication of a test, so republishing does not reset a candidate's allowance

Violations detected in the exam player are recorded server-side against the attempt. They are gathered into a per-attempt conduct report with a timeline.

On device binding, the honest description is the useful one. It identifies a browser profile. It guards against casual attempt-sharing. An invigilator can reset it.

What is recorded, and for how long?

A shared audit layer spans modules. Creates, updates, deletes, soft-deletes and restores each record as their own type. Deletes capture the full prior value, not a diff.

Sensitive field names are redacted as they are captured, from a named list. Personal data is masked again at render. Session and token tables are excluded.

Records are kept for a retention period you set per account.

Several areas keep their own history alongside that layer:

  • Every grade, re-grade and un-grade writes a numbered row. Nothing is overwritten.
  • Question edits write sequential version snapshots.
  • Question banks keep a change history.
  • Proctor messages are stored with their delivery status, so you can evidence what a candidate was told.

A module firewall sits in the request pipeline alongside tenant resolution. It keeps both a change log and an access log.

How are uploaded files served?

Uploaded files are served through expiring signed URLs. Each link carries an expiry and a signature. A link that has been altered, or that has passed its expiry, is refused.

Links are short-lived by default. Exam content and examiner sessions get a longer window, so a long sitting is never interrupted.

Route keys map to a fixed allow-list of storage containers. An unrecognised key is refused, not resolved. Blob keys are opaque, so a path cannot be walked. Signatures are stripped before a path is stored, so a signed link is never replayed.

Third-party credentials held on your behalf are encrypted at rest. No endpoint ever returns them.

How is security verified before a release ships?

StudyDrome runs documented tenant-isolation reviews per module, with recorded PASS/SHIP verdicts. A security-auditor pass gates every milestone.

Need more than this page covers? Hosting, data handling, sub-processors, your own questionnaire — bring it to a pilot conversation. We answer in writing.

How do staff sign in with our own identity provider?

Through per-tenant OpenID Connect. StudyDrome supports Google, Microsoft, Okta and generic OIDC providers, configured per institution. Two provisioning modes are available. Just-in-time creates a recognised user on first sign-in. Pre-provisioned-only requires the account to exist before the provider will admit them.

How does StudyDrome keep our data separate from another institution's?

By account id, in two layers. Tenant-owned records inherit a base class that refuses to build without a valid account id. And each module's data context adds a global filter to every tenant-owned table, so a query that omits its own filter still cannot cross. The tenant itself is resolved from the signed request. Never from request input.

How do we end a compromised session?

From the session list, or centrally. A user sees their own active sessions with the address, browser and start time of each, and can end any. An administrator with the sessions permission can end every session for a user. That is written to the activity log with the count. Refreshing rotates tokens and revokes the previous one.

What is recorded when data changes, and how long is it kept?

Creates, updates, deletes, soft-deletes and restores are each captured as their own operation type. Deletes record the full prior value. Sensitive field names are redacted at capture, and personal data is masked again at render. Records are kept for a retention period you set per account.

How are exam files protected from being shared?

Through expiring signed URLs. Each link carries an expiry and a signature, so an altered or expired link is refused. Links are short-lived, and exam content gets a longer window so a sitting is never interrupted. Route keys resolve against a fixed allow-list of containers. Signatures are stripped before a path is stored, so a link cannot be replayed.

How do we restrict where an exam can be taken from?

With an address allow-list that accepts single addresses and ranges. It is checked when a candidate prepares, starts and resumes. So moving off-campus mid-exam is caught on the next resume. It fails closed: an address that cannot be parsed is refused.

How is security verified before a release ships?

StudyDrome runs documented tenant-isolation reviews per module, with recorded PASS/SHIP verdicts. A security-auditor pass gates every milestone. Does your review need detail beyond this page? Bring your questionnaire to a pilot conversation. We answer in writing.

Book a pilot

Book a pilot

Related