Skip to content

ADR: Cloudflare Access for Operator Authentication

  • Status: Accepted
  • Date: 2026-04-23
  • Decider: Jeffrey Lambert
  • Project: Admin Dashboard Cloudflare Migration

Context

The legacy admin dashboard owns its own authentication, meaning employee credentials sit inside the Adventive product surface. This creates avoidable risk: credential rotation, MFA enforcement, offboarding, and auditing all have to be maintained as first-party concerns inside an application whose primary job is customer / billing operations.

Adventive already runs behind Cloudflare, uses Cloudflare Tunnel for other internal surfaces, and is actively migrating toward a Cloudflare-Workers platform. Cloudflare Access provides an identity-aware proxy that terminates authentication at the edge, so the admin never sees credentials — only a signed JWT identifying the authenticated operator.

Decision

Operator authentication for the new admin will be enforced by Cloudflare Access, not by application-managed sessions. The admin API Worker and admin UI will both sit behind an Access policy. The Worker reads CF-Access-Jwt-Assertion (or the Cf-Access-Authenticated-User-Email header) for operator identity and derives RBAC from there.

Directory backend

The Cloudflare Access directory integration is deferred. Candidate identity providers are:

  • JumpCloud — already integrated elsewhere at Adventive.
  • Google Workspace — also a candidate via OIDC / SAML.

Cloudflare Access abstracts the directory choice from the application, so this can be wired up (and even changed) later without touching admin code. The admin team is not blocked on the directory decision.

Consequences

Positive: - No employee passwords or session tokens live inside the Adventive product. - Login, MFA, device posture, and offboarding are handled once at the Cloudflare edge. - Access logs become a single audit surface rather than per-application. - Matches the direction of other Adventive internal surfaces (Cloudflare Tunnel, Public API Worker).

Negative / to-mitigate: - Local development needs a pattern for simulating Access headers (typically a dev-only bypass or a service token). - RBAC logic still lives in the admin API — Access provides identity, not authorization. The admin must still map operator identity to permitted actions. - Emergency access path must be designed if Cloudflare Access is ever unavailable.

Follow-ups

  • Define the admin's RBAC model (what roles exist, what each role can do) once operator workflows are inventoried.
  • Choose directory provider (JumpCloud vs. Google Workspace) before go-live.
  • Document the local-dev auth bypass pattern in the runbook.
  • Confirm whether Cloudflare Access policies should gate the UI (Pages) as well as the API, or whether API-only gating is sufficient.