> Connect your identity provider to Modelux so your team signs in with their work account. # SAML SSO overview Modelux supports **SAML 2.0** for workforce single sign-on. Connect your identity provider (IdP) — Okta, Microsoft Entra ID, Google Workspace, JumpCloud, OneLogin, or any SAML-compliant IdP — and members of your org sign in with their work account instead of a password. SSO is available on the **Enterprise** plan. Pair it with [SCIM provisioning](/docs/guides/scim) to automate user lifecycle. ## When do I need this? You need SSO when any of these apply: - Your IT / security team requires federated auth for every SaaS - You want one-click deactivation when someone leaves the company - You need SOC 2 or ISO 27001 evidence for access control - Your organization has more than ~25 seats If none of those apply, password + Google + passwordless email login is probably simpler. ## How Modelux's SAML works Modelux is a **SAML 2.0 service provider (SP)**. Your IdP authenticates the user and sends a signed assertion back to Modelux, which creates the session. Two login entry points are supported: - **SP-initiated:** user visits `app.modelux.ai/login`, clicks "Use SAML SSO", enters their work email, and we redirect them to your IdP. - **IdP-initiated:** user clicks the Modelux tile in their workforce portal (Okta dashboard, myapps.microsoft.com, etc.) and lands straight in the Modelux dashboard. On first login, Modelux **just-in-time provisions** the user into your org with the default role you configured. If they already have a Modelux user with a matching verified email, we merge — no duplicate accounts. ## What you'll need Before starting: - An **admin** or **owner** role in your Modelux org - An account with **app-administrator** rights in your IdP (to register a new SAML app) - A verified email domain you can add a DNS TXT record to ## High-level setup The flow is the same for every IdP: 1. In Modelux → **Settings → SSO**, note these three values. Your IdP needs them to register Modelux as a service provider: - **SP Entity ID** (e.g. `https://app.modelux.ai/api/sso/metadata`) - **Assertion Consumer Service URL** (e.g. `https://app.modelux.ai/api/sso/saml/acs`) - **SP metadata XML** (we publish the full metadata document — some IdPs let you import from a URL) 2. Create a new SAML app in your IdP and paste those values. 3. Copy three values **back** from the IdP into Modelux's **Settings → SSO** → Identity provider form: - **IdP Entity ID** (often called *Identifier* or *Issuer URL*) - **IdP SSO URL** (the SAML 2.0 Single Sign-On URL) - **IdP Certificate** (PEM-encoded x509 signing certificate) 4. Set a **default role** for new SSO users (member is usually right). 5. Click **Test connection** — this validates the cert parses without attempting a live login. 6. Click **Save**. 7. Add your email domain under **Email domains**, publish the TXT record we give you at `_modelux.`, and click **Verify**. Once verified, anyone signing in from `you@your-domain.com` is automatically routed to your org's IdP. 8. Once the flow works end-to-end for at least one test user, flip **Require SAML for all members** to block password / Google logins for people in your org. ## Provider-specific guides - [Okta](/docs/guides/sso-okta) - [Microsoft Entra ID](/docs/guides/sso-entra) (formerly Azure AD) - [Google Workspace](/docs/guides/sso-google) > Using JumpCloud, OneLogin, or another IdP? The setup follows the same > pattern — any IdP that exports standard SAML 2.0 metadata works. > Follow the high-level flow above. If you hit a snag, email > support@modelux.ai and we'll walk you through. ## Attribute mapping Modelux reads these attributes from the SAML assertion (first match wins per field): | Field | Claims we read | | --- | --- | | Email | `email`, `emailAddress`, `mail`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`, `urn:oid:0.9.2342.19200300.100.1.3`, or the NameID if it is an email | | First name | `firstName`, `givenName`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`, `urn:oid:2.5.4.42` | | Last name | `lastName`, `surname`, `sn`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`, `urn:oid:2.5.4.4` | | Display name | `displayName`, `name`, `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`, `cn` | Most IdPs emit the first set of names by default. If yours is picky about URIs, use the OIDs — those are the SAML 2.0 canonical forms. ## Enforcement With **Require SAML for all members** enabled, Modelux rejects every non-SAML login for anyone who is a member of your org. Google and passwordless email sign-ins return a friendly banner pointing them at the SSO flow. Don't enable this until: - You've tested the flow end-to-end with a non-admin account - Your domain is DNS-verified - At least one owner can log in via SSO (so a bad IdP config doesn't lock every owner out — owners retain their SSO identity through provider changes) If you do lock yourself out, email support@modelux.ai — we can disable enforcement for you. ## Rotating the IdP certificate IdP signing certs expire. When yours is about to rotate: 1. Get the new PEM from your IdP 2. Paste it into the **IdP certificate** field in Modelux and save 3. The current fingerprint shown next to the field updates — verify it matches what your IdP shows Modelux stores the cert encrypted at rest and only ever audits the SHA-256 fingerprint.