Security & Sign-On

Security & Sign-On

1. What it is

Security & Sign-On is the administration surface where you set password rules, require two-factor authentication, configure SSO providers, control session lifetimes, and review who signed in and how. Every login door — password, SSO, OTP code, magic link — is governed by the policies you set here.

• Access: Admin → Security Settings (the page is titled “Sign-in Policies”). Requires the Administrator role; some operations (session revocation, authentication log) require Super Admin.
• What it is not: This is not where you manage attendance-specific security (clock-in fraud prevention, kiosk PINs, IP validation for punches) — that lives under Admin → Attendance Settings on a separate page.

2. Standing it up

1. Go to Admin → Security Settings. The page shows your current sign-in policies with their defaults already active — every new business starts with password complexity on, 2FA required for Super Admin and Administrator roles, and a 60-minute inactivity timeout.
2. Review the Password Policies card. The defaults require at least 8 characters with uppercase, lowercase, and numbers. Special characters are not required by default. Adjust if your compliance framework requires more.
3. Review the Two-Factor Authentication card. By default, Super Admin and Administrator roles must enroll in 2FA at their next login. Turn on “Require for all users” if your policy demands it. Users in required roles who have not enrolled are redirected to the 2FA setup screen on their next login — they are not locked out.
4. If you use SSO, go to Admin → SSO Configurations. SSO configuration requires the Standard platform tier. Add a provider (Google Workspace, SAML, Microsoft Entra ID, or MangoApps), test the connection, then enable it. Until you add and enable at least one SSO configuration, the login page shows only the password form.
5. Confirm your session timeout. The default inactivity timeout is 60 minutes (NIST AAL2-aligned). The absolute timeout — the longest a session can live regardless of activity — defaults to 24 hours. Both are visible on the Sign-in Policies page.

Silent-failure pairing: enabling “Remember me” without understanding its effect. When a user ticks “Remember me”, they stay signed in for the configured duration (default 30 days) regardless of the inactivity timeout. The NIST AAL2 compliance badge on the Sign-in Policies page turns to “Outside AAL2” when Remember me is enabled, because a standing credential that outlives the 24-hour absolute cap defeats it.

3. How it fits together

Sign-in policies vs SSO configurations — two separate admin surfaces that work together. Sign-in Policies (Admin → Security Settings) control password rules, lockout, session lifetimes, 2FA, and login recovery for all authentication methods. SSO Configurations (Admin → SSO Configurations) manage the identity providers that appear on the login page. A user who logs in via SSO still has their session governed by the timeout and 2FA settings from Sign-in Policies.

Two-factor authentication — TOTP-based (authenticator app). Users scan a QR code to enrol, receive 10 one-time backup codes, and enter a 6-digit code on each login. 2FA can be required business-wide or per role. Per-role enforcement uses the organizational role hierarchy: you pick which roles must enrol. Service accounts are always exempt (they cannot perform an interactive challenge). OTP login (one-time code sent via email or phone) bypasses 2FA — the one-time code serves as the second factor.

Session lifetime — three controls, resolved in order. Inactivity timeout signs a user out after N minutes of no activity (default 60). Absolute timeout signs them out after N hours regardless of activity (default 24). Remember me, when enabled, extends the session to N days (default 30) and overrides the inactivity timeout. The inactivity timeout resolves tenant setting → platform GlobalSetting → NIST AAL2 default of 60 minutes.

Account lockout — after a configurable number of failed login attempts (default 5), the account is locked for a configurable duration (default 30 minutes). Locked accounts cannot use OTP login either.

SSO providers — four provider types are supported: Google Workspace (OAuth 2.0), SAML (any SAML 2.0 IdP — Okta, PingOne, ADFS, etc.), Microsoft Entra ID (OAuth 2.0), and MangoApps (Hub-to-Ops JWT). A business can have multiple configurations for the same provider type (e.g. two SAML IdPs for different divisions). Configurations are encrypted at rest — client secrets and private keys never leave the server in cleartext. The SAML health check warns when a certificate expires within 30 days.

Authentication log — an append-only audit trail recording every login, logout, failed attempt, and session expiry. Each entry captures the authentication method (password, SSO, OTP, two-factor, magic link, invite, registration, API, mobile, or impersonation), IP address, user agent, and portal. Entries cannot be edited or deleted — the model enforces read-only after creation. Default retention is 395 days (trailing 13 months, aligned to SOC 2 / ISO 27001 evidence windows); the tenant can extend this up to 2,555 days (~7 years).

OTP login — a passwordless login option where users receive a 6-digit code via email or phone. Rate-limited to 3 code requests per 5 minutes, codes expire in 15 minutes (email) or 10 minutes (SMS), and 5 wrong attempts invalidate the code. Enabled by default; disable it on the Sign-in Policies page if your policy requires password-only authentication.

4. Running it

Configuring SSO

1. Go to Admin → SSO Configurations and click New Configuration.
2. Select a provider: Google Workspace, SAML, Microsoft Entra ID, or MangoApps.
3. Enter the provider’s credentials. For SAML, you can paste IdP metadata XML and the system extracts the SSO target URL, certificates, and NameID format automatically. For Google Workspace, upload the OAuth credentials JSON from Google Cloud Console. For Entra ID, provide the client ID, client secret, and tenant ID.
4. Click Test to verify the connection before enabling it.
5. On the SSO Configurations index, toggle the provider on. The login page immediately shows an SSO button for that provider.

Each business can use the platform’s system-level SSO configuration or create its own custom configuration. The SSO Settings page controls which mode each provider uses. When using a system configuration, you can optionally enable JIT (just-in-time) provisioning with a domain allowlist — new users whose email domain matches are auto-created on first SSO login.

Multiple configurations per provider are supported — for example, two SAML IdPs for different divisions. All enabled configurations appear as buttons on the login page. The SSO Configurations index includes a login page preview showing exactly which SSO buttons users see right now.

Reviewing SSO logs

1. Go to Admin → SSO Logs to view SSO-specific login attempts.
2. Filter by SSO configuration, status, or date range.
3. The log shows successes, failures, and the specific SSO configuration used for each attempt — useful when debugging a misconfigured provider.

Checking NIST compliance

The Sign-in Policies page shows a NIST 800-63B (AAL2) compliance badge. It turns green when your settings meet AAL2 requirements (inactivity timeout ≤ 60 minutes, absolute timeout ≤ 24 hours, Remember me disabled). If any setting falls outside AAL2, the badge turns to “Outside AAL2” and lists exactly which settings are non-compliant — the admin sees the tradeoff rather than being blocked.

Signing out users or revoking API tokens

1. Go to Admin → Security Settings → Manage Sessions & Tokens (requires Super Admin).
2. Search for a user by name or email, then click Sign Out to end their sessions.
3. To sign out everyone, type your business subdomain to confirm and click Sign Out All. By default your own session is kept so you can confirm the result.
4. API tokens are listed below sessions. Click Revoke on a token to invalidate it immediately — any integration using it stops working.

Reviewing the authentication log

1. Go to Admin → Authentication Log (requires Super Admin).
2. Filter by event type (login, logout, failed login, session expired), outcome (success, failure), date range, or search by name/email/IP.
3. Export to CSV for compliance evidence. The export includes timestamp, event type, outcome, authentication method, person, email, IP address, portal, failure reason, and user agent.

Authentication logs are retained for a configurable period (default 395 days). The retention period is set on the Sign-in Policies page.

5. Settings

Setting	Where	Default	What it changes
Require Two-Factor Authentication	Sign-in Policies	Off (but see per-role)	When on, every user must enrol in 2FA at next login
Required Two-Factor Roles	Sign-in Policies	Super Admin, Administrator	Roles that must enrol in 2FA even when the business-wide switch is off
Enforce Password Complexity	Sign-in Policies	On	Toggles whether password rules below are enforced
Minimum Password Length	Sign-in Policies	8	Minimum characters
Require Uppercase / Lowercase / Numbers	Sign-in Policies	All on	Character-type requirements
Require Special Characters	Sign-in Policies	Off	Whether passwords must include non-alphanumeric characters
Password Expiration	Sign-in Policies	0 (never)	Days before a password must be changed
Max Failed Attempts	Sign-in Policies	5	Failed logins before lockout
Lockout Duration	Sign-in Policies	30 minutes	How long a locked account stays locked
Session Inactivity Timeout	Sign-in Policies	60 minutes	Minutes of inactivity before sign-out
Absolute Session Timeout	Sign-in Policies	24 hours	Maximum session lifetime regardless of activity
Remember Me	Sign-in Policies	Off	Whether the “Remember me” checkbox appears on the login page
Remember Me Duration	Sign-in Policies	30 days	How long a remembered session lasts
Auth Log Retention	Sign-in Policies	395 days	How long the authentication log keeps entries
Self-Registration	Sign-in Policies	Off	Whether users can register via a public link (admin approval still required)
OTP Login	Sign-in Policies	On	Whether users can log in with a one-time code sent to email or phone
Enforce IP Restrictions	Sign-in Policies	Off	When on, users can only access from explicitly allowed IP addresses

6. More help

• Security & Sign-On FAQ — exact limits and ranges, 2FA setup, SSO troubleshooting, and every “why can’t I sign in” question.
• Users, Roles & Permissions — managing who can access the platform and what they can do.
• Ask AI — the assistant answers questions about security settings from these articles.