> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trylaunchkit.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# SAML 2.0 setup

> Connect Okta, Microsoft Entra, or any SAML 2.0 identity provider

## What LaunchKit expects from your IdP

* **SP-initiated flows only.** Every sign-in starts at LaunchKit (login page or start URL). Unsolicited IdP-initiated responses are rejected, as are replayed assertions.
* **A signed response** carrying the member's **email address**, plus optional first and last name attributes for nicer provisioning.
* Your IdP's **entity ID, sign-on URL, and X.509 signing certificate**, either as three values or as one metadata XML file.

## Setup

<Steps>
  <Step title="Create the connection in LaunchKit">
    In the workspace console open **Workspace, then Security**, choose **SAML**, and save. You will be asked to re-authenticate. The page now shows your service-provider values (ACS URL and SP metadata URL, unique to this connection).
  </Step>

  <Step title="Create the app in your IdP">
    <Tabs>
      <Tab title="Okta">
        Create a **SAML 2.0 app integration**. Set *Single sign-on URL* to the ACS URL and *Audience URI (SP Entity ID)* to the SP entity ID from the security page (or import the SP metadata URL). Map `email` (and optionally `firstName`, `lastName`) as attribute statements. Assign your users or groups to the app.
      </Tab>

      <Tab title="Microsoft Entra">
        Create an **Enterprise application** with SAML single sign-on. Set *Reply URL (ACS)* and *Identifier (Entity ID)* from the security page, or upload the SP metadata. Keep the default claims: `emailaddress`, `givenname`, `surname`. Assign users or groups.
      </Tab>

      <Tab title="Other IdPs">
        Any SAML 2.0 IdP works. Point it at the ACS URL, set the SP entity ID, and make sure the assertion carries the member's email. The SP metadata URL serves standard metadata XML if your IdP can import it.
      </Tab>
    </Tabs>
  </Step>

  <Step title="Hand the IdP details back to LaunchKit">
    On the security page, either **upload your IdP's metadata XML** (entity ID, sign-on URL, and certificate are extracted automatically) or paste the three values manually. Save.
  </Step>

  <Step title="Test, then enable">
    Open the **start URL** in a fresh browser session and complete a sign-in through your IdP. When it works, set the connection to **enabled**. Enforcement is a separate, deliberate step: see [Domains and enforcement](/en/sso/domains-and-enforcement).
  </Step>
</Steps>

<Warning>
  Changing any IdP field (entity ID, sign-on URL, certificate, or the protocol itself) on an **enforced** connection automatically drops enforcement in the same save. This prevents locking the whole workspace out behind a misconfigured IdP. Re-enforce after you have verified a sign-in against the new configuration.
</Warning>

## Provisioning behavior

A first-time SSO sign-in creates the member just-in-time with the connection's **default role** and consumes a seat. Invited members can also accept an invitation through SSO. Sessions established through SSO satisfy MFA requirements; no second factor is prompted.