> ## Documentation Index
> Fetch the complete documentation index at: https://test-8ad8522e-feat-ai-sre.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Single Sign-On
> Sign in once and access multiple connected applications through single sign-on, improving work efficiency and enhancing security
Flashduty supports Single Sign-On (SSO) via SAML2.0, OIDC, CAS, and LDAP (private deployment only) protocols, helping you easily integrate with various applications and platforms. Users only need to sign in once to access multiple connected applications and services without repeated authentication.
## Network Access Requirements
***
Each protocol has different network reachability requirements for your identity provider (IdP). Confirm this before configuring to avoid sign-in failures caused by network access:
| Protocol | Does Flashduty need to reach the IdP? | Details |
| -------- | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| SAML 2.0 | No | Sign-in happens entirely through the member's browser: the browser is redirected to the IdP, then posts the signed SAMLResponse back to Flashduty after login. Flashduty's servers never connect to the IdP directly — the signature is validated locally against the metadata you upload |
| OIDC | Yes | On every sign-in, Flashduty's servers fetch the IdP's discovery document, then call its token endpoint and JWKS endpoint. When the ID Token doesn't carry every mapped field, Flashduty also calls the UserInfo endpoint |
| CAS | Yes | On every sign-in, Flashduty's servers call the IdP's `/serviceValidate` endpoint to validate the login ticket. The CAS protocol offers no alternative — the ticket carries no signed content, so it can only be validated at the source |
| LDAP | Not applicable | Available only in the private deployment version, where Flashduty runs inside your own network — public internet reachability doesn't apply |
If your identity provider is on a private network and not reachable from the public internet:
* You can allow Flashduty's egress IPs — `47.94.95.118`, `123.56.8.183`, `47.94.193.81`, and `1.13.19.96` — through your firewall to open access from Flashduty to the IdP
* If you'd rather not open any public access to your identity provider, **SAML 2.0** is the only protocol that needs none — it's the recommended choice in that case
The egress IPs above apply only to Flashduty's **SaaS (public cloud) service**. If you're using a private (on-premises) deployment, Flashduty runs inside your own network and its egress IP depends on your deployment environment — check with your infrastructure team instead of using the addresses above.
## Configuring SAML Protocol
***
**Configuration path**: Platform Management → Single Sign-On → Enable → Settings → Select SAML2.0 protocol type
| Field | Description |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Protocol Type | Select SAML2.0 |
| Metadata Document | XML document obtained from the identity provider |
| Field Mapping | Flashduty extracts user email, username, and phone information from the identity provider through mapped fields |
| Stable User ID Field (`user_id`) | Optional. The unique user identifier attribute returned by the identity provider, used to recognize the same member; email or phone changes do not affect recognition. If left empty, members are matched by the email/phone fields below. Recommended value: `employee_id`; enter `name_id` to use the NameID (Subject) of the SAML assertion. See [Member Association](#member-association) below |
| Create Account on Sign In | Enabled by default; when disabled, members must be invited before they can sign in |
| SSO-only login (`force_sso`) | Enabled by default. When on, every member of this account can sign in only via SSO; password and verification-code sign-in are rejected. See [SSO-only login](#sso-only-login) below |
| Flashduty Service Provider Info | **Service Provider Metadata** and **Assertion Consumer Service URL** (assertion address for identity provider to call for single sign-on) |
You can sync roles and teams by the names returned by your identity provider. See [Role and team mapping](#role-and-team-mapping). **Leave default roles and default teams empty in most cases to keep fallback assignments off.**
## Configuring OIDC Protocol
***
**Configuration path**: Platform Management → Single Sign-On → Enable → Settings → Select OIDC protocol type
| Field | Description |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Protocol Type | Select OIDC protocol |
| Issuer | Obtained from identity provider, case-sensitive URL that cannot contain query parameters |
| Client ID | Client ID, obtained from identity provider |
| Client Secret | Client secret, obtained from identity provider |
| Field Mapping | Flashduty extracts user email, username, and phone information from the identity provider through mapped fields |
| Stable User ID Field (`user_id`) | Optional. The unique user identifier claim used to recognize the same member; email or phone changes do not affect recognition. If left empty, members are matched by the email/phone fields below. Recommended value: `sub`. See [Member Association](#member-association) below |
| Create Account on Sign In | Enabled by default; when disabled, members must be invited before they can sign in |
| SSO-only login (`force_sso`) | Enabled by default. When on, every member of this account can sign in only via SSO; password and verification-code sign-in are rejected. See [SSO-only login](#sso-only-login) below |
| Scopes | Specifies the information and functionality permissions the request can access, with support for customization. Defaults to `openid`, `profile`, `email`, `phone`; you can add custom scopes as tags |
| Flashduty Service Provider Info | **Redirect URL**: Identity provider callback address
**Supported Signing Algorithms**: RS256, RS384, RS512, ES256, ES384, ES512, PS256, PS384, PS512 (HS256 not supported) |
You can sync roles and teams by the names returned by your identity provider. See [Role and team mapping](#role-and-team-mapping). **Leave default roles and default teams empty in most cases to keep fallback assignments off.**
Scopes is a required field. The default values `openid`, `profile`, `email`, `phone` are the base permissions needed for OIDC to function properly. Removing these defaults may cause single sign-on to fail or prevent correct retrieval of user information. If you need to add custom scopes, add them while keeping the defaults intact.
## Configuring CAS Protocol
***
**Configuration path**: Platform Management → Single Sign-On → Enable → Settings → Select CAS protocol type
| Field | Description |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Protocol Type | Select CAS protocol |
| CAS Address | CAS service address obtained from identity provider, e.g., `https://xqlsd3irx2gm-demo.authing.cn/cas-idp/669e050856d5b07b4399b242` |
| CAS Login Path | CAS login path, e.g., `/login` |
| Skip TLS Check | Optional; when enabled, skips TLS certificate verification, suitable for CAS services using self-signed certificates |
| Field Mapping | Flashduty extracts user email, username, and phone information from the identity provider through mapped fields |
| Stable User ID Field (`user_id`) | Optional. The unique user identifier used to recognize the same member; email or phone changes do not affect recognition. If left empty, members are matched by the email/phone fields below. Recommended value: `principal` (the CAS authenticated username); you can also map it to a returned attribute. See [Member Association](#member-association) below |
| Create Account on Sign In | Enabled by default; when disabled, members must be invited before they can sign in |
| SSO-only login (`force_sso`) | Enabled by default. When on, every member of this account can sign in only via SSO; password and verification-code sign-in are rejected. See [SSO-only login](#sso-only-login) below |
| Flashduty Service Provider Info | **Redirect URL**: Identity provider callback address |
You can sync roles and teams by the names returned by your identity provider. See [Role and team mapping](#role-and-team-mapping). **Leave default roles and default teams empty in most cases to keep fallback assignments off.**
## Role and team mapping
OIDC, SAML2.0, and CAS support syncing member roles and team membership by the **role names and team names** returned by your identity provider. LDAP continues to use [Group DN mapping](#ldap-role-and-team-synchronization), not the name mapping described here.
**Field mappings apply on every sign-in; defaults apply only when creating members.** After you enable the corresponding sync option and configure the role or team field, valid matches replace the member's existing roles or team memberships on every SSO sign-in, including manually assigned ones. With no matches, existing members keep their assignments; only members actually created during this sign-in receive the configured valid defaults. Roles and teams are handled independently.
**In most cases, keep default role and default team fallbacks off by leaving both selections empty.**
Defaults apply **only when the current SSO sign-in actually creates a new member and no names match for the corresponding roles or teams**. Existing members do not receive defaults on sign-in, and changing defaults does not reassign their permissions.
Defaults are still shared rules for this SSO configuration, not settings for an individual member. If a mapping field is empty or incorrect, or the identity provider returns no matching names, **every new member created through this SSO configuration without matches receives the same default roles or joins the same default teams**. Do not select defaults just to make a sign-in test work. In particular, do not use administrator or other privileged roles, or sensitive teams, as general defaults.
### Configuration fields
**Configuration path**: Platform Management → Single Sign-On → Select OIDC, SAML2.0, or CAS → Sync Configuration
| Field | Configuration |
| ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Sync roles (`sync_role_enabled`) | When enabled, updates roles from valid mapping results on every SSO sign-in. Without matches, only new members can receive default roles. When disabled, role sync does not run |
| Role field (`roles`) | The field containing role names, such as `roles`, not a role name or ID. With role sync enabled, matches replace existing roles on **every sign-in**, including manually assigned roles |
| Default roles (`default_role_ids`) | Supports multiple selections. With role sync enabled and no returned role names matching an available role, **only members created during this sign-in** receive these default roles. Existing members are unaffected. **Usually leave empty** |
| Sync teams (`sync_team_enabled`) | When enabled, updates team membership from valid mapping results on every SSO sign-in. Without matches, only new members can receive default teams. When disabled, team sync does not run |
| Team field (`teams`) | The field containing team names, such as `teams`, not a team name or ID. With team sync enabled, matches replace existing team memberships on **every sign-in**, including manually added memberships |
| Default teams (`default_team_ids`) | Supports multiple selections. With team sync enabled and no returned team names matching an available team, **only members created during this sign-in** receive these default teams. Existing members are unaffected. **Usually leave empty** |
Defaults have no separate toggle: to turn fallback assignments off, clear the default role and default team selections. If you do not want SSO to manage roles or teams, turn off **Sync roles** or **Sync teams**, respectively.
### How names match
* Mapping field names are strings. The returned values can be a single string or an array of strings. Use an array for multiple names: `"A,B"` is treated as one complete name and is not split on commas.
* Flashduty trims leading and trailing whitespace, matches names exactly and case-sensitively, and removes duplicate names.
* Roles match the preset names `Admin`, `Responder`, and `Viewer`, or enabled custom roles in the current account. Teams match non-deleted teams in the current account.
* If multiple eligible roles or teams share a name, Flashduty selects the one with the **smallest ID**. Name mapping does not create roles or teams.
* OIDC reads the returned claims, SAML reads assertion attributes, and CAS reads returned user attributes. Field names must match what your identity provider actually returns.
For example, if OIDC returns these claims, enter `roles` as the role field and `teams` as the team field:
```json theme={null}
{
"roles": ["Responder"],
"teams": ["Platform", "Database"]
}
```
Create the example teams in Flashduty first, and replace the returned values with the names you use. **This mapping example requires no default roles or teams.**
### When defaults apply
Roles and teams **match and fall back independently**. For example, if roles match but teams do not, Flashduty uses the matched roles. A new member can receive default teams; an existing member keeps their current teams.
**A first SSO sign-in does not necessarily create a new member.** Members already created or invited by an administrator, and existing members linked to a stable user ID for the first time, do not receive defaults. Defaults apply only when Just-In-Time (JIT) provisioning creates a new member record during the current sign-in.
| Corresponding sync option | Name matching result | Behavior on sign-in |
| ------------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| Off | Any | Does not run this sync; neither mappings nor defaults apply |
| On | At least one match | Uses the matches without adding defaults; ignores unmatched names |
| On | No matches, with valid defaults | New members receive the corresponding defaults; existing members keep their assignments |
| On | No matches and no valid defaults | Does not run this sync: new members follow the existing creation flow; existing members keep their roles or teams |
**A role or team selected as a default role or default team in any saved SSO configuration cannot be deleted.** Deleting the role or team returns `ReferenceExist` (the resource is still referenced by other entities and cannot be deleted). Unselect it in the corresponding SSO configuration's **Default Roles / Default Teams** options and save first. The restriction also applies when SSO or the corresponding sync switch is currently off — the defaults are already saved and re-enabling the configuration must not restore dangling IDs; forced role deletion (`is_force`) does not bypass it either.
**Valid mappings replace assignments; they do not append to them.** On an existing member's next SSO sign-in, valid mapping results can still replace manually assigned roles or teams. A dimension with no matches remains unchanged. To manage roles or teams entirely by hand, disable the corresponding sync option instead of only clearing its defaults.
### Recommended setup order
Confirm that your identity provider returns the correct role and team names for each group of members, then enable the sync options you need. Keep an option off until its mapping is ready.
Use test members to check matching names, missing fields, and unmatched names. Sign in again to confirm the actual role and team changes. Test existing members as well as new members.
Select default roles or teams only when every new member created through SSO without matches should receive the same minimum required permissions or join the same teams. **Otherwise, leave defaults empty to keep fallback assignments off.** Changing defaults does not affect existing members.
See [Role and Team Sync](/en/on-call/integration/sso/role-team-sync) for per-protocol name sources, matching rules, and field retention. LDAP uses Group DN mapping, not the name mapping or new-member default rules in this section.
## Configuring LDAP Protocol
***
LDAP single sign-on is only supported in the **private deployment version**.
**Configuration path**: Platform Management → Single Sign-On → Enable → Settings → Select LDAP protocol type
| Field | Description |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Protocol Type | Select LDAP protocol |
| LDAP URL | LDAP service address, e.g., `ldap://10.10.10.10:389` |
| BIND DN | Username for connecting to LDAP, e.g., `cn=admin,dc=flashduty,dc=com` |
| BIND DN Password | Password for connecting to LDAP, stored encrypted in the database |
| Encryption | Supports **TLS** and **StartTLS** encryption methods (mutually exclusive, only one can be enabled). After enabling either method, you can optionally **skip SSL/TLS certificate verification**; if not skipped, you can optionally provide the SSL/TLS certificate path |
| User DN | Defines where to start searching for users, e.g., `ou=people,dc=flashduty,dc=com` |
| Auth Filter | Custom filter expression for retrieving user DN information, basic form: `(&(mail=%s))`. Note: Opening and closing parentheses are required |
| Field Mapping | Flashduty extracts user email, username, phone, and Group information from the identity provider through mapped fields. Email is a required mapping field. The Group field defaults to `memberOf` and is used for role and team synchronization |
| Stable User ID Field (`user_id`) | Optional. The unique user identifier attribute used to recognize the same member; email or phone changes do not affect recognition. If left empty, members are matched by the email/phone fields below. Recommended value: `uid`; you can also use a stable attribute such as `entryUUID`. See [Member Association](#member-association) below |
| Create Account on Sign In | Enabled by default; when disabled, members must be invited before they can sign in |
| SSO-only login (`force_sso`) | Enabled by default. When on, every member of this account can sign in only via SSO; password and verification-code sign-in are rejected. See [SSO-only login](#sso-only-login) below |
Field mapping must be consistent with the identity provider configuration, otherwise it will cause errors. For specific configuration, refer to [OpenLDAP Integration Guide](/en/on-call/integration/sso/openldap).
### LDAP Connection Test
After configuring the LDAP connection information, you can click **Test connection** below the LDAP form in the **Protocol & connection** section to verify that Flashduty can successfully connect to your LDAP server. The system will attempt to establish a connection using the currently entered LDAP URL, BIND DN, and password, and return a success or failure result.
We recommend running the connection test before saving the configuration to ensure connection parameters are correct, avoiding login failures due to misconfiguration.
### LDAP Role and Team Synchronization
When using the LDAP protocol, you can automatically synchronize Flashduty roles and teams based on the user's LDAP Group membership.
**Configuration path**: LDAP Settings page → Sync Configuration
In the sync configuration area, enable the **Sync Roles** and/or **Sync Teams** toggles.
Click **Add Mapping Rule** and configure the following for each rule:
| Field | Description |
| ---------------- | ----------------------------------------------------------------------------------------------- |
| **Group DN** | The full Distinguished Name of the Group in LDAP, e.g., `cn=devops,ou=groups,dc=example,dc=com` |
| **Mapped Roles** | Available when Sync Roles is enabled; select the Flashduty roles this Group maps to |
| **Mapped Teams** | Available when Sync Teams is enabled; select the Flashduty teams this Group maps to |
When Sync Roles is enabled, you can configure **Default Roles**. When a user's LDAP Groups do not match any mapping rule, the system will assign these default roles.
* You can add multiple mapping rules, each corresponding to one LDAP Group
* When a user signs in, the system automatically matches and synchronizes the corresponding roles and teams based on their LDAP Group membership
* The Group DN in mapping rules must be the full path of the Group in LDAP
## Member Association
***
During single sign-on, the system associates the user returned by the identity provider with a member of the account. The association method depends on whether the SSO configuration has a **Stable User ID Field** set, and this applies to new and existing configurations alike:
| Configuration | Association method |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Stable User ID Field configured | Recognizes the same member by the stable user ID returned by the identity provider; email or phone changes do not affect recognition. If the stable user ID is not yet bound, the system first matches an existing member by email or phone and establishes the stable user ID binding |
| Stable User ID Field not configured (left empty) | Members continue to be associated by the mapped email or phone fields below; behavior stays unchanged |
Make sure the identity provider always returns a stable and unique user ID. A mapping failure (the identity provider does not return the field) will prevent members from signing in.
Changing identity-scope settings (protocol type, identity provider address, or the stable user ID field) is treated as an identity-scope change, and the system rotates the SSO configuration ID. Existing members are re-associated by email or phone on their next sign-in and bound to the new stable user ID.
## SSO-only login
***
The `force_sso` option restricts every member of the account to signing in through SSO, fully delegating authentication to the identity provider.
**Configuration path**: Platform Management → Single Sign-On → Enable → Settings → **Members can only sign in via SSO**
| Item | Behavior |
| ------------- | ------------------------------------------------------------------------------------------------------------------------ |
| Field name | `force_sso` |
| Default | **On** — the toggle on the SSO settings page is pre-filled to enabled the first time SSO is configured |
| When enabled | Every member of the account can sign in only via SSO; password and verification-code sign-in are rejected by the backend |
| When disabled | Members may sign in via SSO, password, or verification code |
| Exemptions | **None.** The account owner and super-admins are also subject to this restriction — there is no bypass branch |
When this option is on and a member attempts password or verification-code sign-in, the login endpoint returns:
```text theme={null}
This account requires SSO login. Password/code login is disabled.
```
The same restriction applies when switching accounts inside a password session: if the target account has `force_sso` enabled, the switch is rejected with `The target account requires SSO login. Switching via password session is not allowed.`
**Operational risk**: Once `force_sso` is on, if the identity provider (IdP) is not reachable or misconfigured, every member of the account — including the account owner — will be locked out. Before turning this toggle on:
1. Sign in end-to-end via SSO with at least one member account to verify the IdP flow works.
2. Make sure the account owner has a working SSO sign-in path, so you cannot accidentally lock yourself out.
3. If the IdP may be temporarily unavailable, keep this toggle off and re-enable it after the IdP is verified.
### Comparison with "Prevent editing external members"
`force_sso` controls **how members sign in** — whether password and verification-code sign-in are allowed. `sso_user_non_editable` ([Prevent editing external members](#external-member-management)) controls **member editability** — whether SSO-synchronized external members can have their profile and role modified in the console. The two settings act on different layers and can be toggled independently.
## External member management
***
When you enable single sign-on, members automatically created through their first SSO login are marked as **external members**. You can enable the **Prevent editing external members** option in SSO settings (disabled by default). When enabled, these external members become read-only in Flashduty — you cannot modify their roles or delete them in Flashduty. All member management must be done through the identity provider.
This feature is ideal for organizations that need to centrally manage user permissions in the identity provider, ensuring member information in Flashduty always stays in sync.
* This option only affects external members created via SSO; manually invited members are not affected
* If the SSO configuration is deleted, existing external members remain read-only by default
## Login Domain Management
***
The login domain is an important identifier for your account, used to locate the correct SSO configuration during single sign-on. Each account's login domain is globally unique.
After configuring the login domain, members can initiate single sign-on directly through the `{domain}.sso.flashcat.cloud` address without manually selecting an identity provider.
You can modify the account domain on the **Platform Management → Organization → Organization Information → Organization Profile** page. The domain must be 5–40 characters long and can only contain letters, numbers, or `-`, and cannot start or end with `-`.
After changing the domain, it will apply to the following scenarios:
* **SSO single sign-on configuration**: All configured SSO login domains will change accordingly. Members will need to use the new domain to initiate single sign-on
* **Email integration push addresses**: The email integration receiving address format is `prefix@{domain}.{email-suffix}`. The address changes when the domain changes, so update related configurations promptly
Before modifying, ensure you have checked your email integration configuration and notified your organization. The modification may require multi-factor authentication (MFA) verification. If you encounter any issues, contact technical support promptly.
* It is recommended to use your company's English name as the login domain for easy memorization
* Once set, changing the login domain will immediately invalidate the old domain; members using the old domain will need to update their login address
## Best Practices
***
SAML2.0/OIDC/CAS sync by name on every sign-in; defaults apply only to new members without matches
Configure Flashduty SSO single sign-on through Authing
Configure Flashduty SSO single sign-on through Keycloak
Configure Flashduty SSO single sign-on through OpenLDAP