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:
- Configure tenant SSO fields in workspace settings.
- Connect your IdP (for example Okta or Azure AD) with the supplied metadata requirements.
- Validate sign-in and group/attribute mapping.
- 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:
- Confirm user email domain and org slug match expected workspace configuration.
- Confirm user is signing into the correct org context.
- Recheck IdP metadata, callback, and certificate validity.
- 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.
Related
- Organizations — workspace boundaries and URLs
- Team & invitations — role and membership behavior
- Troubleshooting — fast remediation checklist