SSO, SCIM & LDAP [SSO: Starter · SCIM/LDAP: Enterprise]
Purpose: authenticate and provision users from your organization's identity provider instead of managing passwords in CMDash directly.
SSO (SAML 2.0 / OIDC sign-in) is available starting on the Starter tier (matching CISO Assistant's free community edition). SCIM and LDAP directory sync remain Enterprise-only.
SSO / SAML 2.0
Configure at Settings → SSO (the Settings hub card is labeled "SAML Single Sign-On").
Supported providers (a dropdown, not free text): Okta, Azure AD (Entra ID), Google Workspace, Ping Identity, or Custom SAML 2.0 IdP.
Setup, as the page is built today:
- Go to Settings → SSO.
- Copy the Service Provider Metadata — CMDash shows the SAML metadata
URL (
/api/auth/saml/metadata/<config-id>) for you to give your IdP. - Under Identity Provider Configuration, pick the Provider, then fill in the IdP Entity ID and the rest of the IdP-side fields the form asks for.
- Save.
- Group mapping is a JSON field on this page (IdP group → CMDash role), not a per-group "Add Mapping" wizard with separate fields.
- Click Run self-test — the link sits under the Service Provider
Metadata block, next to the metadata you just handed your IdP, and opens
the "SSO configuration self-test" page (
/settings/sso/self-test). Run it to validate the configuration and the SCIM provisioning cycle before you roll SSO out to everyone.
No "Enforce SSO" toggle was found on the SSO page in the current source — if your workspace needs to force all non-Owner users through SSO, verify directly against the live page rather than relying on the older instructions this replaces.
The Owner can always fall back to email + password login regardless of SSO configuration, so an IdP outage cannot lock out the whole workspace.
SCIM Provisioning
SCIM is enabled from the SSO page, not from API Keys. On
Settings → SSO, the SCIM Provisioning panel has an Enable SCIM
button. Clicking it returns a bearer token shown exactly once — save it
immediately — plus the SCIM base URL
(<your-instance>/api/scim/v2) to paste into your IdP's provisioning
config.
LDAP Directory Sync
Configure at Settings → LDAP — but note that, unlike every other
Enterprise settings page, this page has no card on the Settings hub.
There is no link to it from Settings or from the SSO page; you have to
navigate to /settings/ldap directly. If your team can't find it, that's
why.
Fields: Server URL, Bind DN, Bind Password, Base DN, User Filter, plus per-attribute mappings (Username, Email, Name attributes). Test Connection validates credentials before you save.
Sync interval is configurable, not fixed. The page offers every 30 minutes, hourly, every 2 hours, every 4 hours, or daily — it is not locked to a 4-hour cadence that requires contacting support to change.
Manual sync: click Sync Now on the same page to trigger an immediate sync outside the schedule.
Verified domains: who SSO, SCIM and LDAP can create
Your identity provider and your directory can create a new CMDash
account only for an address in a domain your organization has verified.
Verify a domain at Settings → SSO → Verified domains: add it, publish
the TXT record shown there at _cmdash-verify.<your domain> with your DNS
provider, then select Verify. Each mail domain is verified on its own (a
subdomain such as eu.example.com needs its own record), and a domain can
be verified by only one CMDash organization. Only the Owner can add, verify
or remove a domain, and each change asks you to confirm your password or
authenticator code first.
For anyone else, CMDash records an invitation instead of creating or attaching an account:
- an address outside your verified domains;
- an address that already has a CMDash account but is not a member of your organization (for example a consultant who uses CMDash with another organization).
These invitations are not e-mailed automatically: they appear on the Members page under Pending Invitations, labelled as coming from SSO, SCIM or LDAP, and an admin sends them — one at a time with Send, or all at once with Send pending invitations (a daily limit applies). The person accepts with their own CMDash credentials; from then on SSO, SCIM and LDAP manage them normally. An LDAP sync records each person once.
CMDash re-checks each verified domain's TXT record every day. If the record is missing or wrong three days in a row, the domain stops being verified, new accounts are no longer created there, and the Owners get a notification. Existing members are not affected; publish the record again and select Verify to restore it.
If you set up SSO, SCIM or LDAP before verified domains existed: people who are already members keep signing in as before. New people are invited instead of created until you verify a domain, and the SSO settings page shows a banner with how many people were invited or turned away in the last 30 days.
Signing in through SSO stays in that organization
A session that started with your organization's SSO sign-in covers that organization only. To switch to another organization you belong to, or to open the admin or customer portal, CMDash first asks you to confirm it is you with your own CMDash password, authenticator app, passkey or recovery code — or you can sign out and sign in with your own credentials. While you are signed in through SSO, the organization switcher lists only the organization you signed in to; choose Switch organization — confirm it’s you to see the others. An authenticator app or passkey that was set up during an SSO session does not count for this: use one you set up after signing in with your own credentials.
When you next sign in with your own credentials (password, e-mail link, Google or Microsoft), CMDash lists any organization that a directory or SSO sign-in added you to, and asks you to Keep or Leave each one.
Related
- Users & Roles — the roles that SSO group mappings and LDAP group-to-role mappings assign into.
- API Keys & Webhooks