Access
Onboarding and login
How organizations request access and how issued operators authenticate. Onboarding does not silently create production tenants without Access Review.
/onboarding . Access request
Public multi-step form: identity (business email), environment (security stack, use cases, size, timeline), and review. Personal, disposable, reserved, and shared-role mailboxes are rejected. Submission creates an application with a reference id and waits for Access Review.
Successful submit does not hand out console passwords by itself. Credentials are issued when a Super Admin approves the application and mail delivery succeeds (when mail is configured).
/login . Operator sign-in
Supports approved operator credentials when AUTH_CREDENTIALS_ENABLED is not false, and Microsoft Entra ID when Azure AD / Entra env vars are present. Okta and generic SAML may appear in the UI as not configured until wired.
Post-login routing depends on role: Super Admin to Access Review, Admin toward Admin/Workspace or callback, analysts toward Command Center or Incidents. Closing the browser typically requires sign-in again unless AUTH_SESSION_PERSISTENT=true.
Session and API identity
The browser holds a NextAuth session cookie. API calls go through /api/beacons, which attaches identity headers derived from that session. Operators should never paste an API bearer token into frontend code or localStorage. If AUTH_SECRET is missing in production, sign-in fails loudly — that is intentional.
Local AUTH_USERNAME / AUTH_PASSWORD is for development only. Production expects Entra (or another wired IdP) plus Access Review to issued memberships.