SAML Single Sign-On
SAML single sign-on (SSO) lets Business and Enterprise organizations connect an external identity provider (IdP) so team members on verified corporate email domains can sign in to Incido through your directory instead of a local password. Administrators configure identity providers in the Dashboard; end users are routed to SAML automatically when their email domain is verified.
SSO is an access and reliability control. When enforcement is enabled on Enterprise plans, password-based sign-in is disabled for verified domains, so a misconfigured IdP can block operators from reaching the Dashboard during an incident. Plan setup and testing carefully before turning enforcement on.
For plan availability and downgrade rules, see Billing and plan changes. For organization-owned accounts provisioned through SAML, see Managed user accounts.
Plan limits
| Limit | Business | Enterprise |
|---|---|---|
| Identity providers (Active + Disabled) | 1 | Unlimited |
| Domains per identity provider | 5 | Unlimited |
| SSO enforcement | Not available | Available |
Pending identity providers in setup do not count toward the identity provider limit. Enterprise subscriptions may have custom limits negotiated with your account contact.
Where to configure
Open Settings → Single sign-on in the Dashboard. Organization administrators with SSO management access can add identity providers, verify domains, run connection tests, and activate SSO.
The list page shows each identity provider's name, status, enforcement flag, domain count, and last update. Use Add identity provider to start setup.
Setup workflow
Each identity provider follows a five-step progress checklist shown on the view page sidebar:
- Configure identity provider — Select a vendor when creating the provider, then complete the in-app configuration form with IdP metadata or manual fields (entity ID, SSO URL, signing certificate, and related values).
- Test connection — Run a popup-based connection test that validates the SAML assertion without creating a session.
- Add email domain — Add the corporate email domains that should route users to this identity provider.
- Verify DNS — Prove domain ownership with a DNS TXT record.
- Activate identity provider — Turn on SSO routing after a successful connection test.
The view page is split into a main workflow column (setup instructions, connection test, domain verification) and a sidebar (progress checklist, general settings, user provisioning, and SSO enforcement).
Configure identity provider
When you add an identity provider, you choose the vendor only. Incido creates a Pending record and opens the view page with vendor-specific numbered setup instructions.
Follow the in-app instructions to configure your IdP admin console. Each vendor guide covers navigation in the external console, copying ACS URL and Entity ID from Incido into the IdP, assigning user access, mapping attributes, and exporting metadata. The final step links back to the Configure action in the Dashboard.
After saving IdP configuration in Incido, inline setup instructions are replaced by on-demand access through View setup instructions in the page header.
Test connection
Once the identity provider is configured, run Test connection. Incido opens a popup that performs a service-provider-initiated SAML login.
The test succeeds only when the SAML assertion includes:
- A corporate email address (public domains such as gmail.com are rejected)
- A given name
- A family name
On success, Incido records the test timestamp and automatically adds the email domain from the assertion if it is not already listed. The test does not sign you in or activate the identity provider.
You can re-run the test at any time from Test connection on Active or Disabled identity providers.
Add and verify domains
Add each email domain your organization uses for Incido access. Domains can be added while the identity provider is still in setup.
For the first unverified domain, Incido shows inline DNS TXT instructions. Each domain also has its own Verify domain action. After you publish the TXT record, click Verify domain or wait for automatic background checks (approximately every five minutes).
SSO routing applies only to verified domains. You can activate an identity provider before all domains are verified, but users on unverified domains will not be routed to SAML until verification completes.
Enter DNS records exactly as shown in the Dashboard. The TXT value is unique per domain and remains stable if you remove and re-add the same domain later.
Activate
Activate is available after a successful connection test. If domains are still unverified, Incido shows a warning but allows activation.
After activation, the identity provider status becomes Active and verified domains route users to SAML at login.
Supported identity providers
Incido includes setup instructions and troubleshooting tailored to these vendors:
| Vendor | Notes |
|---|---|
| Microsoft Entra ID | Metadata XML or manual fields |
| Google Workspace | Custom SAML app in Google Admin |
| Okta | SAML 2.0 application |
| OneLogin | SAML connector |
| JumpCloud | SAML SSO application |
| Auth0 | SAML addon |
| PingFederate / ADFS | Requires SP signing certificates (see below) |
| Other SAML provider | Generic manual configuration |
Step-by-step IdP console instructions are shown in the Dashboard during setup and through View setup instructions. This documentation describes the Incido-side workflow; follow the in-app vendor guide for external console navigation.
Service provider values and attribute mapping
During setup, Incido displays values your IdP needs:
- Entity ID — Service provider entity identifier
- Assertion Consumer Service (ACS) URL — Where the IdP sends SAML responses
- Metadata URL — SP metadata for IdP import
Map directory profile fields so the SAML assertion includes identity attributes. Recommended attribute names are firstName, lastName, and email. Incido also accepts common alternatives (for example givenName, familyName, mail, and standard WS-Federation claim URIs).
The connection test fails if any of email, given name, or family name is missing from the assertion. During live login, missing names fall back to a generic display name so sign-in can still proceed, but you should fix attribute mapping before relying on SSO in production.
User provisioning
Automatic user provisioning is enabled by default when you create an identity provider. When someone signs in through SAML for the first time and automatic provisioning is on, Incido creates their account and adds them to your organization with the configured default role.
| Setting | Purpose |
|---|---|
| Automatic user provisioning | Create accounts on first SAML sign-in |
| Default role | Organization role assigned to newly provisioned users |
| Incident responder | Whether new users are eligible for on-call |
| Provision new users as managed | New JIT users become managed accounts (when managed users is enabled) |
When automatic provisioning is off, only users who are already organization members can sign in through SAML. Others are rejected.
Existing members who sign in through SAML keep the roles administrators assigned earlier; SAML does not change their role on subsequent logins.
For organization-owned accounts, see Managed user accounts.
SSO enforcement
On Enterprise plans with the SSO enforcement feature, you can require SAML sign-in for all users on verified domains.
When enforcement is enabled:
- Users on verified domains must sign in with SAML unless they are on the exception list
- Password sign-in, password reset, and profile password management are blocked for enforced users
- The exception list must include at least one user who can manage SSO settings, so your team retains break-glass access if the IdP is unavailable
Configure enforcement and the exception list in the identity provider sidebar after the provider is Active or Disabled.
End-user sign-in
Incido uses an email-first login flow:
- The user enters their email address.
- Incido checks whether the email domain is verified for an identity provider in any organization they belong to.
- If the domain is covered:
- With enforcement on, the user is redirected to the IdP (except break-glass users on the exception list). Google sign-in is not available for that domain.
- With enforcement off, users without a password are redirected to SAML; users with a password see the password step and an optional Continue with single sign-on button. Users may also sign in or register with Google when it is enabled for the platform.
- If the domain is not covered, the user continues with password sign-in or Google (when configured).
Password reset requests for SSO-enforced domains are not processed (the reset form still shows a generic success message for security). Break-glass users on the exception list can still reset passwords.
For profile and password behavior, see Profile, password, and API tokens.
Adding users on SSO domains
When you invite or add a user whose email domain is verified for your organization's identity provider, Incido adds them to the organization immediately without sending an invitation email. You must provide their given name and family name.
The user can sign in through SAML on first access. This direct-add path follows the same user and responder seat limits as standard invitations.
For invitation and role workflows, see Users, roles, and invitations.
Identity provider lifecycle
| Status | Meaning |
|---|---|
| Pending | Setup in progress; not used for login routing |
| Active | Verified domains route users to this IdP |
| Disabled | Temporarily off; configuration is preserved and can be re-enabled without repeating setup |
You can disable an Active identity provider to pause SSO routing without deleting configuration. Deleting an identity provider releases its domain claims so the domains can be added to another provider later.
SP signing certificates
Most vendors do not require Incido to sign authentication requests. For PingFederate / ADFS and similar deployments, Incido manages service provider signing certificates automatically.
When signing certificates apply:
- Incido generates certificates with a three-year validity period
- A pending successor certificate is created before the active certificate expires
- Expiry notices are sent to the organization contact email at 60, 30, and 7 days before expiry
- Administrators can promote pending certificates and roll back within a short window after promotion
Manage certificates from the identity provider view page when the vendor policy requires them.
What changes on the public frontend
SAML configuration does not change public status page content. It affects who can sign in to the Dashboard and publish updates. If SSO is misconfigured or the IdP is unavailable, operators may be unable to reach incident and maintenance workflows, which can delay customer-facing communication.
Operational effects
Treat SSO setup as part of your incident-readiness checklist. Verify connection tests, DNS, attribute mapping, and break-glass access before enabling enforcement. Align default provisioning roles with Users, roles, and invitations so new SAML users receive appropriate access for Incidents and on-call workflows.
Troubleshooting
The connection test popup does not open. Allow popups for the Incido Dashboard site in your browser settings.
The test reports a missing email address, given name, or family name. Return to the Configure step and confirm attribute mapping in your IdP matches the recommended fields.
You see a signature or certificate error. Re-import IdP metadata or verify the signing certificate in your IdP matches your Incido configuration.
The test rejects a public email domain. Sign in with a corporate email address on a domain you plan to verify.
The assertion audience or ACS URL does not match. Re-copy the Entity ID and ACS URL from the Incido Configure step into your identity provider.
Google reports app_not_configured_for_user. In Google Admin, open the SAML app and turn on user access for the test user or their group. Google may take about five minutes to propagate changes.
Attribute mapping looks correct but the test still fails. Confirm the IdP sends attributes on the assertion, not only in the SAML response envelope. Wait for IdP propagation and retry.
Users on a verified domain are not redirected to SAML. Confirm the identity provider is Active, the domain shows as verified, and the user's email domain matches exactly.
A user cannot sign in after enforcement was enabled. Verify the IdP is reachable and the user is assigned to the SAML application. Add break-glass users to the exception list before enforcement if local password access is required.
Plan change or feature removal is blocked. You cannot remove SAML SSO while any identity provider is Active or Disabled with pending or verified domains. You cannot remove SSO enforcement while enforcement is enabled on any identity provider. Reduce IdP or domain counts to fit the target plan before downgrading.