[view as .md]

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 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.<your-domain>, 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

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

FieldClaims we read
Emailemail, 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 namefirstName, givenName, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname, urn:oid:2.5.4.42
Last namelastName, surname, sn, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname, urn:oid:2.5.4.4
Display namedisplayName, 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.