Platform Foundation

SSO & Identity

OIDC and SAML federation with Entra ID, Okta, Google Workspace, or any standards-compliant IdP. Native email/password is available as a controlled fallback.

Why this matters for enterprise procurement

Your IT team has onboarded a dozen SaaS vendors this year. FrontLine fits the standard playbook — SAML 2.0 / OIDC, SCIM provisioning, just-in-time user creation, group-mapped role assignment — so no bespoke integration work is needed and access reviews fold into your existing IdP processes.

How it's implemented

Standards-based federation, configured the way your IT team expects

We support SAML 2.0 (preferred for enterprise IdPs) and OIDC with PKCE. Group-to-role mapping is re-evaluated on every sign-in, so role changes in your IdP take effect on next session. IdP client secrets are encrypted at rest using a stable SSO_SECRET_KEY that survives deploys. JWT session tokens carry the tenant claim and are immutable for the request lifecycle. Native email/password is disabled by default in production tenants; per-tenant flags can re-enable it for break-glass scenarios.

Capabilities

What's covered out of the box

SAML 2.0 with attribute-based group mapping

OIDC with PKCE

Pre-tested integrations with Entra ID, Okta, Google Workspace

SCIM 2.0 user provisioning

Just-in-time provisioning with role defaults

Force-SSO enforcement per tenant (no password fallback)

Device-trust cookies signed via a stable secret

Authentication events emitted to the audit trail

Standards & compliance

Audit-ready artifacts your reviewers can lean on

SOC 2 Type II audit in progress — access-management controls
Aligned with NIST 800-63B AAL2 for authenticator assurance
ISO/IEC 27001 access-control framework
Encrypted IdP secrets via age-keyed SOPS at deploy time

Procurement FAQ

What security and compliance reviewers actually ask

Can you enforce SSO-only access with no password fallback?+

Yes. A per-tenant force-SSO flag disables all password-based authentication, including break-glass accounts.

How do you handle IdP role changes mid-session?+

Role assignments are re-derived from IdP group membership on every sign-in. Removing a user from an IdP group revokes their access on their next session.

What happens to existing sessions when an IdP connection is rotated?+

Existing JWT sessions remain valid until their expiry (default 8 hours). Rotating the IdP connection forces re-authentication on the next sign-in.

Are authentication events logged?+

Every sign-in, sign-out, MFA challenge, password reset, and failed attempt is recorded in the immutable audit trail with IP, user agent, and IdP claim hash.

Run this past your security team

We share security overviews, RLS policy DDL, audit-event schemas, and SOC 2 progress on request. Book a 30-minute security review with the founders.

Book a security review Back to the Atlas