GloriousFlywheel Dashboard Admin Auth Workflows 2026-04-16

GloriousFlywheel Dashboard Admin Auth Workflows 2026-04-16

Snapshot date: 2026-04-16

Purpose

Capture the first real admin-focused auth workflow for #172.

Previous slices established:

  • tailnet-first request identity precedence
  • signed session handling
  • operator/admin write-side mutation checks
  • authenticated viewer baseline for non-public APIs

This slice turns admin into more than a stronger rank value by adding a real auth-administration workflow inside Settings.

Companion notes:

Current Executed Admin Auth Workflow

Admins now have three executed auth-administration surfaces in Settings:

  1. runtime auth-policy summary
  2. passkey inventory and revocation across users
  3. recent auth event history for interactive session and passkey lifecycle actions

This is intentionally scoped. It does not yet make the dashboard a full auth administration system.

What Admins Can Now Do

1. Inspect Auth Runtime Shape

Admins can view:

  • whether session signing is enabled
  • whether trusted proxy headers are enabled
  • the current proxy default role
  • whether interactive GitLab login is enabled
  • whether passkey auth is enabled
  • allowlist counts for admin, operator, and viewer identities

This exposes policy shape without exposing secret values or raw identity lists.

2. Inspect Passkey Inventory

Admins can now see registered dashboard passkeys across users, including:

  • username
  • user id
  • device type
  • backup/sync state
  • creation time
  • last-used time
  • abbreviated credential id

3. Revoke Passkeys Across Users

Admins can now revoke any registered dashboard passkey through the current admin-only passkey inventory flow.

4. Inspect Recent Auth Event History

Admins can now review recent auth security events tied to passkey lifecycle and interactive session actions, including:

  • successful GitLab OAuth login
  • successful WebAuthn login
  • interactive logout
  • passkey registration
  • self-service passkey removal
  • admin passkey revocation across users
  • actor identity, role, and auth method for those actions
  • target username and credential id when available

This means interactive auth activity and passkey administration are no longer silent side effects.

Why This Is A Good Next Step

This workflow is grounded in current repo reality:

  • the dashboard already stores WebAuthn credentials in PostgreSQL
  • revocation is an existing primitive
  • the workflow fits the current auth and settings surfaces
  • it improves operator safety without pretending the repo has a broader IAM system than it actually does

Current Boundary

This workflow still does not make admins responsible for:

  • editing allowlists from the dashboard
  • changing session-secret or proxy trust configuration from the dashboard
  • managing org-scoped role bindings
  • administering a future non-GitLab mutation authority

Exit Condition

  • admin has a real executed auth-administration workflow
  • auth-policy introspection is no longer the only admin-only surface
  • interactive login, logout, and passkey lifecycle actions now leave a durable audit trail
  • the next admin/auth step can focus on policy change authority instead of basic credential governance

GloriousFlywheel