How do I set up SAML SSO and SCIM provisioning in LaunchDarkly Enterprise?

Moving faster in LaunchDarkly Enterprise shouldn’t mean losing control of who gets access. SAML SSO and SCIM provisioning let you centralize identity, automate onboarding and offboarding, and keep permissions aligned with your internal policies—without manually managing users in LaunchDarkly.

Quick Answer: In LaunchDarkly Enterprise, you configure SAML SSO so your teams authenticate through your identity provider (IdP), then enable SCIM provisioning so the IdP can create, update, and deactivate members (and, for Okta, sync teams) automatically. Together, they give you single-source-of-truth identity and enforceable access control at scale.

The Quick Overview

What It Is: SAML-based single sign-on plus SCIM user provisioning between LaunchDarkly Enterprise and your identity provider.
Who It Is For: Enterprise organizations that need centralized access control, automated user lifecycle management, and auditability across large engineering, product, and data teams.
Core Problem Solved: Eliminates manual user administration, reduces access drift and permission risk, and keeps LaunchDarkly membership aligned with your internal identity and security policies.

How It Works

SAML SSO and SCIM work together as your identity control plane for LaunchDarkly:

SAML SSO delegates authentication to your IdP, so members log in with the same credentials and MFA they use elsewhere. This enforces your corporate sign-on rules and keeps auth consistent.
SCIM provisioning lets your IdP push identity changes to LaunchDarkly—creating, updating, and deactivating members (and syncing teams with Okta) automatically when HR or IT updates user records.

Configuration happens once in LaunchDarkly Enterprise and your IdP. After that, user access is governed centrally by your identity system, while LaunchDarkly focuses on runtime control: feature flags, AI Configs, and experiment governance.

1. Plan your access model

Before you touch SSO settings, decide how you want to govern access in LaunchDarkly:

Define naming conventions
- Projects, environments, flags, teams, and contexts should follow clear, predictable patterns.
- This makes it easier to map your IdP groups to LaunchDarkly teams and policies later.
Design your team and role structure
- Identify which groups need production access vs. non-production.
- Define teams (for example, web-platform, mobile-ios, data-science) and the roles each team should have.
- Plan how IdP groups will correspond to LaunchDarkly teams to minimize manual mappings.
Decide on SSO + SCIM scope
- Confirm which business units, geographies, or subsidiaries will be tied to the same IdP and LaunchDarkly org.
- Identify who will administer SSO/SCIM: security, IT, or a shared platform team.

2. Configure SAML SSO in LaunchDarkly Enterprise

SSO is the foundation—set this up first so authentication is centralized.

Gather IdP metadata
From your identity provider (for example, Okta, OneLogin, Azure AD, Ping), collect:
- SAML issuer / entity ID
- SSO URL (login URL)
- X.509 certificate
- Any required attributes (typically email, name, and optional group information)
Configure SSO in LaunchDarkly
In the LaunchDarkly UI (Enterprise plan):
- Navigate to your account/organization settings and find the Single sign-on (SSO) section.
- Choose SAML SSO as the method.
- Enter the IdP metadata:
  - SAML issuer / entity ID
  - SSO URL
  - X.509 certificate
- Define the attribute mappings:
  - Email → LaunchDarkly email
  - First/last name → LaunchDarkly display name
  - Optionally, group or role attributes if you plan to map them.
Set up SSO in your IdP
In your IdP:
- Create a new SAML app/integration for LaunchDarkly.
- Use LaunchDarkly’s ACS URL and SP entity ID (found in the SSO configuration screen) when prompted.
- Configure the NameID or primary identifier as the user’s email.
- Map the required SAML attributes (email, name, optional group).
- Assign users or groups who should have access to LaunchDarkly.
Test SSO flow
- Use the “Test SSO” or similar option in LaunchDarkly to trigger an IdP-initiated login.
- Confirm a test user can log in and that their profile details (email, name) are correct.
- Validate that logouts behave as expected and that SSO covers all intended user entry points.
Enforce SSO (optional/when ready)
Once you’ve verified the flow:
- Enable SSO enforcement so users must authenticate via your IdP instead of local credentials.
- Communicate the change to users, especially if they’re currently using passwords or other auth modes.

Using SSO ensures compliance with your internal access control policies and makes managing multiple large teams easier—without juggling separate credentials.

3. Enable SCIM provisioning for automated user management

With SSO in place, SCIM keeps LaunchDarkly membership in sync with your identity source of truth.

LaunchDarkly supports SCIM provisioning with:

Okta
OneLogin

SCIM lets your IdP:

Create new members in LaunchDarkly automatically.
Update member details (name, email, department changes).
Deactivate members when they leave the organization or change roles.
For Okta: perform team sync so team membership in LaunchDarkly tracks IdP group membership.

A. Enable SCIM in LaunchDarkly

Go to your organization or security settings in LaunchDarkly.
Find the SCIM provisioning section.
Generate a SCIM API token / bearer token specifically for your IdP integration.
Copy the SCIM base URL and token—you’ll paste these into Okta or OneLogin.

B. Configure SCIM in Okta

In Okta, open the LaunchDarkly application you created for SSO.
Navigate to the Provisioning tab.
Under Integration, enable provisioning and enter:
- SCIM base URL from LaunchDarkly
- SCIM token as the Authorization header (usually “Bearer <token>”)
Test the SCIM connection to ensure Okta can reach LaunchDarkly’s SCIM endpoint.
Under To App, enable:
- Create Users
- Update User Attributes
- Deactivate Users
Configure attribute mappings so Okta attributes (email, name, groups) map correctly to LaunchDarkly fields.
For team sync with SCIM (Okta only):
- Map relevant Okta groups to LaunchDarkly teams.
- Verify that adding a user to an Okta group adds them to the corresponding LaunchDarkly team and grants appropriate permissions in one step.

C. Configure SCIM in OneLogin

In OneLogin, open your LaunchDarkly app configuration.
Go to the Provisioning section.
Provide the SCIM base URL and SCIM bearer token from LaunchDarkly.
Enable:
- Create
- Update
- Delete/Deactivate user capabilities as supported.
Map OneLogin user attributes to LaunchDarkly fields.
Assign users and roles to the LaunchDarkly app so changes sync via SCIM.

D. Validate provisioning behavior

Test the full lifecycle:

Create a user in your IdP or assign an existing user to the LaunchDarkly app:
- Confirm a member appears in LaunchDarkly with the correct teams and roles.
Update a user (name, department, email if supported):
- Verify the changes propagate to LaunchDarkly.
Deactivate or unassign a user from LaunchDarkly in your IdP:
- Ensure the user is deactivated in LaunchDarkly and loses access.

SCIM lets you add a member to LaunchDarkly, assign them to a team, and grant permissions in a single IdP-driven step—no manual onboarding in the LaunchDarkly UI.

4. Connect SSO and SCIM to governance

With SAML SSO and SCIM in place, you can enforce stronger policies:

Role- and team-based access control
Use teams and roles in LaunchDarkly to define who can manage flags, projects, environments, metrics, or teams. SCIM keeps membership up to date.
Auditability
Enterprise plans include audit logs for flag and segment changes, so you can see exactly who changed what and when—critical for regulated environments.
Consistency across environments
Map IdP groups to LaunchDarkly teams aligned to specific environments (for example, only SREs can edit production flags), and let SCIM maintain membership.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
SAML SSO Integration	Authenticates LaunchDarkly users via your existing SAML-capable IdP.	Centralizes authentication, enforces corporate MFA and password policies, and reduces login friction.
SCIM User Provisioning	Lets your IdP create, update, and deactivate LaunchDarkly members.	Eliminates manual user management, reduces access drift, and keeps membership aligned with HR/IT systems.
Team Sync with SCIM (Okta)	Syncs team membership based on Okta groups during provisioning.	Grants permissions in one step—assign to a group in Okta, and the right teams and roles are applied in LD.
Granular Access Policies	Defines access levels to flags, projects, environments, metrics, or teams.	Enforces least privilege and separates duties across engineering, product, and data teams.
Audit Logs (Enterprise)	Captures flag and segment changes for review and compliance.	Provides traceability for who changed what, helping you investigate incidents and meet compliance requirements.

Ideal Use Cases

Best for enterprises with regulated access controls: Because SAML SSO ensures authentication follows your internal security standards, and SCIM keeps account status and team membership consistent with your IdP.
Best for organizations with large, dynamic teams: Because SCIM provisioning automatically handles joiners, movers, and leavers—no ticketing backlog, no stale access hanging around in LaunchDarkly.

Limitations & Considerations

SCIM provider support: SCIM integrations are available with Okta and OneLogin. If you’re using another IdP, you may need to rely on SSO alone or use API-based scripts for user sync until native SCIM support is available.
Team sync scope (Okta only): Team sync via SCIM is currently available for Okta. Other providers can still create/update/deactivate users via SCIM but may not support automatic team mappings in the same way.

Pricing & Plans

SAML SSO and SCIM provisioning are Enterprise-grade capabilities designed for organizations that need centralized identity governance and auditability.

Enterprise Plan: Best for large or regulated organizations needing SAML SSO, SCIM provisioning, audit logs, custom roles, and advanced policies across multiple teams and environments.
Other Plans: May support core feature-flagging workflows but typically do not include full SSO + SCIM + audit capabilities. If you’re scaling beyond a single team or managing sensitive workloads, Enterprise is usually the right fit.

For exact feature availability and pricing, check the LaunchDarkly pricing page or talk to sales.

Frequently Asked Questions

Do I need SSO before I can enable SCIM provisioning?

Short Answer: Yes, you should configure SAML SSO first and then layer SCIM provisioning on top.

Details: SSO establishes your IdP as the source of truth for authentication and enforces your sign-on policies across LaunchDarkly. Once that’s stable, SCIM takes over user lifecycle management—creating, updating, and deactivating members automatically. This sequence prevents situations where users are provisioned but can’t authenticate correctly, and it keeps your identity flow coherent: authenticate via SSO, manage via SCIM.

Can I manage teams and roles entirely through my IdP?

Short Answer: Partially—user creation and membership can be driven from your IdP, but you still define teams, roles, and policies in LaunchDarkly.

Details: With SCIM, your IdP can create, update, and deactivate members in LaunchDarkly. For Okta, team sync lets you map groups to teams so membership flows from Okta. However, the structure of teams, roles, and access policies remains defined in LaunchDarkly itself. This keeps your runtime control model—who can manage which flags, projects, environments, and metrics—consistent with how LaunchDarkly is used day to day, while still letting identity and membership come from your IdP.

Summary

Setting up SAML SSO and SCIM provisioning in LaunchDarkly Enterprise gives you runtime control over access just as strong as your runtime control over features and AI behavior. SSO centralizes authentication through your IdP, enforcing corporate security policies and simplifying sign-on. SCIM provisioning then automates user lifecycle management—creating, updating, and deactivating members and, with Okta, syncing teams—so your LaunchDarkly org always mirrors your source-of-truth identity system.

The result: fewer manual admin tasks, less permission drift, and a safer, more auditable way to let thousands of people ship changes in production—without adding 2am access headaches.

Next Step

Get Started