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

Moving faster shouldn’t mean losing control of who can access LaunchDarkly or what they can do. Setting up SAML SSO and SCIM provisioning in LaunchDarkly Enterprise gives you centralized identity, clean access governance, and painless user lifecycle management—without manual cleanup work or 2am permission fixes.

Quick Answer: In LaunchDarkly Enterprise, you configure SAML SSO so users authenticate through your identity provider (IdP), then enable SCIM provisioning so that same IdP can create, update, deactivate, and (for Okta) team‑sync members automatically. Together, they enforce your access policies at runtime with less operational overhead.

The Quick Overview

• What It Is: A SAML‑based single sign-on and SCIM provisioning setup that connects LaunchDarkly to your enterprise identity provider for centralized authentication and user management.
• Who It Is For: Enterprise organizations that need strict access control, auditability, and automated onboarding/offboarding across large teams using LaunchDarkly.
• Core Problem Solved: Manual user and team management doesn’t scale. SAML SSO + SCIM let you enforce policies from your IdP, keep membership in sync, and reduce the chance of stale access or misconfigured permissions.

How It Works

At a high level, LaunchDarkly treats your IdP as the source of truth for who can log in and what groups they belong to. SAML SSO handles runtime authentication; SCIM handles lifecycle events (create, update, deactivate) and, for Okta, team sync. Your admins design roles, teams, and naming conventions in LaunchDarkly, then map IdP groups to those constructs so people get the right access as soon as they sign in.

1. Plan & prepare your structure:
   Define projects, environments, teams, roles, and naming conventions before you wire in SSO/SCIM. This ensures automated provisioning lands users in the right place.

2. Configure SAML SSO for authentication:
   In your IdP, set up LaunchDarkly as a SAML app and configure SSO in LaunchDarkly so users sign in with existing corporate credentials and your global security policies.

3. Enable SCIM provisioning for lifecycle & teams:
   In supported IdPs (Okta, OneLogin), turn on SCIM so user creation, updates, deactivation, and (with Okta) team sync happen automatically, in one step, based on your identity source.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
SAML SSO	Lets members authenticate to LaunchDarkly using your enterprise IdP	Centralized, compliant access control with fewer login credentials to manage
SCIM User Provisioning	Creates, updates, and deactivates members in LaunchDarkly from your IdP	Scales user management and reduces stale accounts or permission drift
Team Sync with SCIM (Okta)	Automatically assigns users to LaunchDarkly teams when they’re added in your IdP	One-step onboarding: add to a group once, get the right teams and permissions automatically

Step-by-step: How to set up SAML SSO in LaunchDarkly Enterprise

This is the sequence I recommend when you’re doing this in a real enterprise environment.

1. Prepare your LaunchDarkly structure and naming

Before you connect your IdP:

• Define projects and environments:
  Decide how you’ll segment risks (for example: core-app / production, core-app / staging, ml-services / production). Enforce a naming convention.
• Design teams and roles:
  Decide which teams should control which flags, projects, and environments. Use roles and custom roles to scope access cleanly.
• Document naming conventions:
  For projects, environments, flags, teams, and context kinds. This gives you stable targets for group‑to‑team mappings later.

These prep steps mean SSO/SCIM can safely drop users into a well-structured system instead of a free‑for‑all.

2. Configure LaunchDarkly as a SAML app in your IdP

In your identity provider (Okta, OneLogin, Azure AD, etc.):

1. Create a new SAML application:
   • Name it “LaunchDarkly” so admins and users recognize it.
   • Set the appropriate SAML 2.0 settings (ACS URL, Entity ID) as provided by LaunchDarkly’s SSO configuration page.
2. Assign users and groups:
   • Add the groups that should have LaunchDarkly access (for example, feature-flags-admins, experimenters, frontend-engineers).
   • If you plan to map groups to LaunchDarkly teams, keep your IdP group names predictable and aligned with your naming conventions.

3. Configure SAML SSO in LaunchDarkly

In LaunchDarkly (you’ll need organization‑level admin permissions):

1. Open the SSO configuration section:
   • Navigate to your organization settings and select the Single sign-on configuration.
2. Enter SAML details from your IdP:
   Typically you’ll provide:
   • IdP SAML metadata URL or upload metadata XML
   • Issuer / Entity ID
   • SAML endpoint (SSO URL)
   • X.509 certificate for signature validation
3. Configure attribute mappings (if available):
   • Map email, name, and (optionally) groups from SAML assertions.
   • Align the group attribute with what your IdP sends (for example, Groups or memberOf).
4. Test SSO with a pilot group:
   • Use your IdP’s “Test” or LaunchDarkly’s SSO test flow to ensure:
     • Users can sign in successfully.
     • The right attributes (especially email and groups) are passed.
5. Enforce SSO if required:
   • Once validated, you can enforce SSO so members must sign in via your IdP, centralizing authentication and policy enforcement (MFA, conditional access, etc.).

At this point, authentication is centralized. Now you eliminate manual user/admin work with SCIM.

Step-by-step: How to set up SCIM provisioning in LaunchDarkly Enterprise

1. Understand what SCIM does in LaunchDarkly

From LaunchDarkly’s side, SCIM:

• Lets your IdP create, update, and deactivate members in LaunchDarkly.
• Works with Okta and OneLogin as first‑class SCIM integrations.
• Supports team sync with SCIM for Okta, meaning:
  • You can add a member to LaunchDarkly, assign them to a team, and grant them permissions in a single step from Okta.

The result: you manage access where identity already lives, and LaunchDarkly stays in sync.

2. Enable SCIM in your IdP (Okta or OneLogin)

In your IdP:

1. Locate the LaunchDarkly SCIM integration:
   • If you created a standard LaunchDarkly app, enable SCIM provisioning in that app.
2. Configure the SCIM base URL and token:
   • In LaunchDarkly, generate a SCIM API token in the SCIM/provisioning settings.
   • Copy the SCIM endpoint URL and token into your IdP’s provisioning settings.
3. Enable provisioning actions:
   • “Create users”
   • “Update user attributes”
   • “Deactivate users”
   • For Okta: “Assign to groups / team sync” as supported.

Make sure you follow your IdP’s guide for “Enable SCIM provisioning” for LaunchDarkly—this ensures the correct schema and attributes are used.

3. Map IdP groups to LaunchDarkly teams and roles

This is where the up‑front naming discipline pays off.

• For Okta team sync:

  • Use Okta groups as the source of truth for LaunchDarkly team membership.
  • Map Okta groups (for example, ld-flag-admins, ld-read-only) to LaunchDarkly teams that already have defined roles and permissions.
  • When you add someone to an Okta group:
    • Okta provisions them to LaunchDarkly (if they don’t exist yet).
    • SCIM team sync adds them to the mapped LaunchDarkly team.
    • The team’s role grants the correct access in one step.

• For OneLogin or non‑team‑sync flows:

  • Use SCIM to provision users and manage lifecycle.
  • Manage team membership directly in LaunchDarkly or via API/automation scripts if you need fine‑grained control.

4. Test SCIM provisioning safely

Before rolling to everyone:

1. Create a test group in your IdP (for example, ld-sandbox).
2. Assign a small pilot set of users to that group.
3. Observe in LaunchDarkly:
   • New users appear as members.
   • Profile updates (name, email, etc.) propagate correctly.
   • Deactivating a user in the IdP removes or deactivates them in LaunchDarkly as expected.
4. Test team sync (Okta only):
   • Add and remove users from an Okta group mapped to a LaunchDarkly team.
   • Confirm that LaunchDarkly team membership changes accordingly.

Once this looks clean, you can extend SCIM provisioning to your real production groups.

5. Roll out to the rest of your organization

Gradually widen the blast radius:

• Onboard additional groups (per product area, function, region).
• Communicate to engineering and product teams that:
  • They use SSO to log in going forward.
  • Access changes happen via the IdP, not manual requests in LaunchDarkly.
• Decommission local accounts or out‑of‑band access paths to keep policy consistent.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Centralized authentication via SAML SSO	Routes all LaunchDarkly sign‑ins through your existing IdP	Enforces your MFA, conditional access, and password policies consistently
SCIM‑driven user lifecycle	Automatically creates, updates, and deactivates users from IdP events	Reduces operational toil and minimizes stale or orphaned accounts
Team sync with Okta	Connects Okta groups directly to LaunchDarkly teams	One-click access changes with predictable permissions for each team
Audit logs & policies	Logs flag, segment, and access changes for review	Supports compliance audits and incident postmortems
Fine-grained API access	Lets you define access levels to flags, projects, environments, metrics, and teams	Aligns runtime release control with least‑privilege security models

Ideal Use Cases

• Best for large enterprises with multiple product teams: Because SSO + SCIM ensure that when someone joins, moves teams, or leaves the company, their LaunchDarkly access follows automatically—no spreadsheet, no manual cleanup.
• Best for regulated or security‑sensitive environments: Because centralizing authentication and provisioning through your IdP makes it much easier to prove who had access to what during audits and to immediately cut access when needed.

Limitations & Considerations

• IdP support scope:
  SCIM provisioning is officially integrated with Okta and OneLogin. If you use another IdP, you may need to rely on SAML SSO for auth plus the LaunchDarkly API or bulk member tools for lifecycle management.

• Team sync availability:
  Team sync with SCIM is available for Okta only. With other SCIM providers, you still get user provisioning/deprovisioning, but team membership may need to be managed directly in LaunchDarkly or via custom automation.

• Plan/edition differences:
  Some advanced governance controls (fine‑grained API access, audit logs, etc.) are tied to specific LaunchDarkly plan tiers. Verify your Enterprise plan’s capabilities when designing your access model.

Pricing & Plans

LaunchDarkly Enterprise plans include the governance and scale features most relevant to SSO/SCIM:

• Core Enterprise: Best for organizations needing SAML SSO and SCIM to standardize access across multiple teams and products while keeping identity centralized in their IdP.
• Advanced Enterprise / Enterprise with enhanced governance: Best for organizations needing SSO + SCIM plus granular API access controls, advanced audit logs, custom roles, and complex multi‑team structures.

For exact pricing, supported IdPs, and which SSO/SCIM features are included in each plan, talk directly with LaunchDarkly or your account team.

Frequently Asked Questions

Do I need both SAML SSO and SCIM provisioning, or is SSO alone enough?

Short Answer: SSO alone centralizes login, but SCIM is what actually scales user and team management.

Details:
SAML SSO ensures everyone authenticates through your IdP, which is essential for MFA, conditional access, and single sign‑out. However, without SCIM:

• You still need to manually add, update, or deactivate LaunchDarkly members.
• Team membership and permissions can drift over time.
• Offboarding depends on a human remembering to remove access.

Adding SCIM means your IdP becomes the definitive source of truth. When HR or IT updates a user in the IdP, LaunchDarkly reflects it automatically—greatly reducing risk and operational overhead. For large or regulated organizations, I strongly recommend enabling both.

Can I bulk add members if I can’t use SCIM yet?

Short Answer: Yes. If you can’t use SCIM, you can still bulk add members directly in LaunchDarkly and manage access manually.

Details:
Some organizations can’t immediately integrate SCIM (for example, IdP limitations, phased rollout, or internal security reviews). In those cases:

• You can bulk add members directly in LaunchDarkly.
• Use teams, roles, and naming conventions to keep access structured.
• Later, when SCIM is approved, you can connect your IdP and progressively move groups onto automated provisioning.

This phased approach lets you benefit from SSO now and adopt SCIM when your identity governance process is ready.

Summary

Setting up SAML SSO and SCIM provisioning in LaunchDarkly Enterprise aligns your runtime release control with your identity and security posture. SAML centralizes authentication so every LaunchDarkly login flows through your IdP. SCIM keeps membership and (for Okta) teams in sync automatically—creating, updating, and deactivating users as their status changes. When combined with LaunchDarkly’s teams, roles, policies, and audit logs, you get a system where access is predictable, auditable, and easy to manage, even as you scale to many projects and environments.

Next Step

Get Started