Security & SSO

Updated 2026-04-18

Use this page when your team asks: "Who can change security settings?" or "How does SSO map into org access?"

Security settings in workspace

Security controls live in Settings -> Security inside an organization (/org/your-slug?tab=settings&settings=security).

Role required: Owner/Admin can edit workspace security policy. Editor/Viewer can view policy only.

Common policy fields include:

  • MFA expectations for privileged users
  • Password quality/rotation policy intent
  • Workspace-level guardrails and audit notes

These settings communicate enforcement intent for your org. Platform-level auth controls still apply globally.

SSO and identity mapping

SSO setup is in Settings -> SSO (/org/your-slug?tab=settings&settings=sso).

Role required: Owner/Admin can configure SSO tenant details. Editor/Viewer have read-only visibility.

Typical SSO workflow:

  1. Configure tenant SSO fields in workspace settings.
  2. Connect your IdP (for example Okta or Azure AD) with the supplied metadata requirements.
  3. Validate sign-in and group/attribute mapping.
  4. Confirm JIT-provisioned users are placed into expected org role defaults.

Provisioning expectations

Automated provisioning is enterprise-oriented and depends on your identity configuration and contract setup.

If sign-in does not work

Follow this order:

  1. Confirm user email domain and org slug match expected workspace configuration.
  2. Confirm user is signing into the correct org context.
  3. Recheck IdP metadata, callback, and certificate validity.
  4. Validate account role and project scope after sign-in.

If still blocked, capture org slug, user email, and UTC timestamp, then escalate via your support flow.