Manage users, roles, and SSO

Administrator tasks in Workbench: who can sign in, single sign-on, reviewing the audit trail, checking readiness, and the deployment-wide timezone and findings-sensitivity settings. Configuration variables are defined in Configuration; this page is the how-to.

Users and roles

Workbench has three fixed roles, enforced on the server for every action — the UI reflects your role but is never what grants access:

The first administrator is created during first-run bootstrap. This local break-glass admin always exists, independent of any identity provider.

Manage members

Admins manage members from the Users page (/users):

• Invite — enter an email, display name, and role. Workbench emails an invitation link when SMTP is configured; otherwise it shows a one-time link you can copy and share. The invited person sets a local password (or signs in via SSO, if configured) to activate the account.
• Change role — pick a new role for a member. It takes effect on their next request: their existing sessions are revoked so a reduced role cannot outlive the change.
• Deactivate / reactivate — a deactivated member keeps their account but cannot sign in; their active sessions are revoked immediately. Reactivate to restore access.
• Remove — permanently remove a member (with a confirmation step).

A last-admin guard keeps the workspace from losing its final administrator: you cannot demote, deactivate, or remove the last active admin.

Multi-user (more than one member) is a Business-tier capability. On Starter / Professional the workspace stays single-user; a tier downgrade never deletes members or locks anyone out — existing members keep their access, and only new invites are blocked.

Reset a password

A member who signs in with a local password can reset it from the login page. Workbench emails a one-time, one-hour reset link (requires SMTP); completing the reset sets the new password and signs that account out everywhere. SSO-only accounts have no password to reset — they sign in through the identity provider.

Single sign-on (OIDC and SAML)

SSO is configured with environment variables (there is no SSO settings page), then verified by signing in. HTTPS is enforced on the redirect/callback. See Configuration for the full variable definitions.

OIDC

Set WORKBENCH_OIDC_ENABLED=true and the required fields:

Optional: WORKBENCH_OIDC_PROVIDER_NAME (the login-button label). The requested scopes are openid email profile, and the email_verified claim must be true.

For a self-hosted or private IdP, two endpoint-policy opt-ins relax the default same-origin/public-address rule — WORKBENCH_OIDC_ALLOWED_ENDPOINT_HOSTS and (development only) WORKBENCH_OIDC_ALLOW_INSECURE_LOOPBACK. Both are described in Configuration; use them only when your IdP's endpoints are cross-origin or on a private address.

SAML

Set WORKBENCH_SAML_ENABLED=true and the required fields:

Optional: WORKBENCH_SAML_SIGN_REQUESTS (default on), WORKBENCH_SAML_PROVIDER_NAME, WORKBENCH_SAML_EMAIL_ATTRIBUTE, WORKBENCH_SAML_METADATA_REFRESH_INTERVAL (default 24h).

Auto-provisioning (first-login)

By default, SSO binds to members you have already invited: a first-time user with no Workbench account is rejected. To let new employees sign in without a manual invite, turn on auto-provisioning by setting an allowed-email-domain list for the provider:

• WORKBENCH_OIDC_ALLOWED_DOMAINS / WORKBENCH_SAML_ALLOWED_DOMAINS — a comma-separated list of email domains. It is both the on/off switch and the authorization gate: a first-time user whose verified email domain matches is created and bound on first login; a non-matching domain is rejected. Empty (the default) means auto-provisioning is off, and the invite-only behavior above is preserved unchanged.

New users default to the viewer role. To derive roles from IdP groups, map group names with WORKBENCH_{OIDC,SAML}_GROUP_ROLE_MAP (e.g. wb-admins:admin,wb-editors:editor), reading the groups from the configurable WORKBENCH_{OIDC,SAML}_GROUPS_CLAIM / _GROUPS_ATTRIBUTE. The highest matched role wins, and admin is granted only through an explicit group→admin entry — never as a default. Auto-provisioning requires the Business tier and a bootstrapped deployment (a local admin must already exist); the role map is applied at first-login creation only. See Configuration for the full variable list.

Verify an SSO change

After enabling or changing SSO, restart Workbench, then:

• Check Readiness (below) — it reports which auth methods are configured and whether SSO is entitled by your license.
• Open /login: the provider button should appear.
• Sign in, and confirm the audit log shows auth.oidc.login.success (or auth.saml.login.success). A failure is recorded as the matching …login.failure event.

Break-glass — you can't be locked out

Local-password login is always enabled for the bootstrap admin — the "break-glass" path. If an SSO change is wrong (bad metadata, a private endpoint rejected, an expired secret), the admin can still sign in with the local password and fix it; there is no flag that disables local login. For a rejected private-IdP endpoint, add its host to WORKBENCH_OIDC_ALLOWED_ENDPOINT_HOSTS and restart. Roll back a bad change by restoring the previous environment variables and restarting.

Audit log

The Audit log (/audit-log) is an immutable record of operator actions. Filter it by event name, actor, and time window (it uses a closed set of event names — there is no free-text search). Security- sensitive events to watch include:

• Authentication — auth.bootstrap.completed, auth.login.success / auth.login.failure, auth.oidc.login.success/failure, auth.saml.login.success/failure, auth.session.expired, auth.logout.
• Settings — settings.timezone_changed, settings.findings_sensitivity_changed, settings.locale_changed.
• Licensing — license.activation.success/failure, license.replaced, license.invalidation.exported.
• Data — database.registered, database.updated, database.deleted; finding status changes (finding.status_changed).

Readiness

The Readiness page (/readiness) is a read-only attestation of the deployment's posture — use it before and after any identity-provider or license change. It reports the Workbench version; the license plan, status, and expiry; which auth methods are configured and whether SSO is entitled; audit retention and cadence; integration count; and the at-rest data-handling posture. It raises closed warnings, including:

• SSO is entitled by the license but neither OIDC nor SAML is configured.
• Audit retention is zero (no automatic sweep).
• The license expires within 30 days, or none is activated.

Timezone and findings sensitivity

Both are on Settings (/settings), admin-only, and apply to the whole deployment:

• Timezone — an IANA zone (e.g. Europe/Amsterdam; default UTC). Timestamps are stored in UTC and displayed in this zone; changing it re-formats views without altering stored times.
• Findings sensitivity — the default severity detail on the findings list: Critical & high only, Balanced (recommended), or Everything incl. preventive. It is a display default — nothing is deleted; raising it reveals more findings, lowering it hides the less-urgent ones.

Both changes are recorded in the audit log.

Language

Also on Settings (/settings), admin-only, applying to the whole deployment: the interface language. Supported languages are English, German, Spanish, French, Italian, and Portuguese.

Changing the language does two things:

• The interface switches immediately.
• New analysis reports are generated in the active language. Reports already produced keep the language they were written in — history is intentionally mixed-language and is never retranslated.

Non-English languages require a Professional plan or higher. On lower plans the selector is limited to English; if a non-English language is applied another way (see below), reports are still written in English, because a lower model tier cannot translate to the required quality.

To start a deployment in a given language before the first sign-in, set the analyzer's ELEVARQ_LOCALE (e.g. pt) at install time — the very first report is then produced in that language, with no need to open Workbench first. The Settings toggle is for changing it later; that change is pushed to the analyzer so subsequent reports follow it.

The change is recorded in the audit log (settings.locale_changed).

Advice re-reporting

Also admin-only on Settings (/settings): the per-severity Advice re-reporting windows control how often the same advice is re-filed across analysis runs. Each severity takes 1–365 days; an empty field uses the default, and critical always reports. The behavior, the default ladder, and the standalone-analyzer environment variables are documented in Advice re-reporting.

Related

• Configuration — the SSO and audit environment variables in full.
• First-run bootstrap — creating the first administrator.
• Reading the status surfaces — operational status.
• Security posture — the master key and transport security.