Single Sign-On

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 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 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. 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 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 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)

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 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 below
Flashduty Service Provider Info	Redirect URL: Identity provider callback address

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, 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:

{
  "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

Configure name mapping and leave defaults empty

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.

Test members with and without matches

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.

Configure defaults only for an intentional shared fallback

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 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 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 below

Field mapping must be consistent with the identity provider configuration, otherwise it will cause errors. For specific configuration, refer to OpenLDAP Integration Guide.

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

Enable Synchronization

In the sync configuration area, enable the Sync Roles and/or Sync Teams toggles.

Add Mapping Rules

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

Configure Default Roles

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.

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:

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:

Sign in end-to-end via SSO with at least one member account to verify the IdP flow works.
Make sure the account owner has a working SSO sign-in path, so you cannot accidentally lock yourself out.
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) 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

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

Role and Team Sync

SAML2.0/OIDC/CAS sync by name on every sign-in; defaults apply only to new members without matches

Authing Integration

Configure Flashduty SSO single sign-on through Authing

Keycloak Integration

Configure Flashduty SSO single sign-on through Keycloak

OpenLDAP Integration

Configure Flashduty SSO single sign-on through OpenLDAP

Home

Products

Platform

Developer

Compliance

Changelog

Network Access Requirements

Configuring SAML Protocol

Configuring OIDC Protocol

Configuring CAS Protocol

Role and team mapping

Configuration fields

How names match

When defaults apply

Recommended setup order

Configuring LDAP Protocol

LDAP Connection Test

LDAP Role and Team Synchronization

Member Association

Comparison with “Prevent editing external members”

External member management

Best Practices

Role and Team Sync

Authing Integration

Keycloak Integration

OpenLDAP Integration

​Network Access Requirements

​Configuring SAML Protocol

​Configuring OIDC Protocol

​Configuring CAS Protocol

​Role and team mapping

​Configuration fields

​How names match

​When defaults apply

​Recommended setup order

​Configuring LDAP Protocol

​LDAP Connection Test

​LDAP Role and Team Synchronization

​Member Association

​SSO-only login

​Comparison with “Prevent editing external members”

​External member management

​Login Domain Management

​Best Practices

Role and Team Sync

Authing Integration

Keycloak Integration

OpenLDAP Integration

Network Access Requirements

Configuring SAML Protocol

Configuring OIDC Protocol

Configuring CAS Protocol

Role and team mapping

Configuration fields

How names match

When defaults apply

Recommended setup order

Configuring LDAP Protocol

LDAP Connection Test

LDAP Role and Team Synchronization

Member Association

SSO-only login

Comparison with “Prevent editing external members”

External member management

Login Domain Management

Best Practices