Dashboard

The dashboard is admin UI inside your app. It covers AuthServer, Audit Logs, communications, and FGA.

Accessing the dashboard#

Default path is DashboardBasePath (/sqlos). Register SqlOS. Call app.MapSqlOS() after Build().

Example: http://localhost:5062/sqlos/. Protect it by assigning dashboard options in the AddSqlOS callback:

options.Dashboard.AuthMode = SqlOSDashboardAuthMode.Password;
options.Dashboard.Password =
    builder.Configuration["SqlOS:Dashboard:Password"]
    ?? throw new InvalidOperationException("SqlOS dashboard password is required.");

The password can come from user secrets, an environment variable, or another configuration provider, but SqlOS does not bind the SqlOS configuration section automatically.

Production exposure#

/sqlos and /sqlos/admin are administrative endpoints for users, organizations, memberships, clients, OIDC/SAML connections, security settings, sessions, audit events, and FGA data. In production, keep them on a trusted network or place them behind HTTPS, reverse-proxy or edge rate limiting, and an admin access layer such as VPN, identity-aware proxy, SSO, or MFA.

Password mode includes dashboard-specific per-IP throttling, global backoff for distributed failures, temporary lockout, and audit events for login success, login failure, rate-limit rejection, lockout, and logout. Treat those built-in controls as a baseline, not as the only protection for a publicly reachable admin surface.

Authenticate operator API calls#

Routes under /sqlos/admin/** are operator surfaces, not public management APIs. The dashboard UI is the normal interactive client. For durable automation, prefer a trusted backend that injects the relevant SqlOS service and authorizes the caller, or put the routes behind your identity-aware operator boundary.

In password dashboard mode, a short-lived curl session can use a cookie jar. This example reads the password without placing it in shell history and uses jq only to JSON-escape the value:

export SQLOS_DASHBOARD_COOKIE_JAR="$(mktemp)"
read -rsp "SqlOS dashboard password: " SQLOS_DASHBOARD_PASSWORD && echo
 
jq -n --arg password "$SQLOS_DASHBOARD_PASSWORD" '{password: $password}' \
  | curl --fail --silent --show-error \
      -c "$SQLOS_DASHBOARD_COOKIE_JAR" \
      -H 'Content-Type: application/json' \
      --data-binary @- \
      http://localhost:5062/sqlos/dashboard-auth/login
 
unset SQLOS_DASHBOARD_PASSWORD

Admin API examples in this documentation use:

curl -b "$SQLOS_DASHBOARD_COOKIE_JAR" \
  http://localhost:5062/sqlos/admin/auth/api/organizations

The cookie jar contains an operator session. Restrict its permissions, never commit it, and delete it when finished:

rm -f "$SQLOS_DASHBOARD_COOKIE_JAR"
unset SQLOS_DASHBOARD_COOKIE_JAR

With callback dashboard auth, authenticate through the host's configured operator flow instead; a password-mode cookie cannot bypass that boundary. See Production Readiness before exposing any admin route.

Auth Server pages#

Audit Logs#

Audit Logs are a top-level governance surface. Filter by organization, application/client, source, action, actor, target, date range, result/status metadata, or free text. CSV export uses the same filters and is bounded for dashboard use.

Auth emails#

The Auth Page settings screen includes email branding for built-in OTP, invitation, and password-reset emails. It stores the application name, logo data URL, primary color, accent color, and background color used by the default templates.

For the end-to-end workflow, see Brand hosted authentication and email. Exact feature references remain in Email OTP, Email Invitations, and Email Branding.

Delegated SSO setup#

Open an organization, choose the SSO tab, and create a setup link when a customer IT admin should configure SAML themselves. The link is scoped to one organization, can be revoked from the same tab, and opens /sqlos/admin/auth/sso-portal instead of the full dashboard.

Follow Let customer admins set up enterprise SSO for the full platform and customer-admin journey, including edge routing, token handling, DNS ownership, enrollment policy, testing, and revocation.

The portal shows Microsoft Entra, Okta, Google Workspace, and generic SAML setup paths. It displays copy-ready SP Entity ID and ACS URL values, verifies the customer email domain through a DNS TXT record, accepts pasted or uploaded metadata XML, validates the IdP entity ID, SSO URL, and signing certificate, then lets the customer activate, disable, replace metadata, and run a SAML test redirect.

Portal launch, open, revoke, provider selection, domain verification, metadata import, activation, disable, and test actions are audit logged with the organization id.

Hosts can disable the bundled portal and redirect opened sessions to their own admin UI with SsoPortal.BuildUiUrl. The same setup state machine is available at /sqlos/admin/auth/sso-portal/api/setup by default.

MFA policy#

The MFA page controls application-wide authenticator-app policy:

• enable or disable MFA;
• enable authenticator apps;
• allow voluntary user self-enrollment;
• issue recovery codes;
• require MFA for all users;
• require MFA for owners, admins, or custom role names;
• edit the available factor list.

If MFA settings are managed by a startup seed, the dashboard shows a startup-managed callout because code/config will reapply those values on restart.

Organization-specific MFA policy is available through the admin API and startup seeding in this release. Use it when one tenant requires MFA and another tenant leaves it optional.

For setup details, see MFA and TOTP and Require Authenticator MFA.

FGA pages#

FGA pages are native routes in the unified dashboard document. They mount the same bundled FGA component for every list and detail workflow, so direct navigation and refresh retain the complete FGA experience without a nested frame or a second dashboard shell.

Sessions#

The Sessions page lists who is signed in, how, which client, and when it expires.