Skip to main content

Set up Enterprise SSO with any SAML provider

Use Custom SAML when your identity provider is not Okta, Microsoft Entra ID, or Google Workspace. Any provider that speaks SAML 2.0 works, including OneLogin, Ping Identity, ADFS, JumpCloud, Auth0, Duo, and self-hosted providers such as Keycloak or Shibboleth.

📝 Note: Enterprise SSO is an enterprise feature and is not enabled by default. To turn it on for your organization, reach out to your Devs.ai representative.

You will need: edit access to Organization Settings in Devs.ai, administrator access to your identity provider, and the list of email domains to route through it. See the overview for the full prerequisites.

Because every provider words things differently, this guide is organized around the four values each side needs rather than around one product's menus.

Terminology map​

Your provider almost certainly uses different labels for the same SAML concepts. Use this to translate:

Devs.ai calls itYour provider may call it
ACS URLAssertion Consumer Service URL, Single sign-on URL, Reply URL, Recipient, Destination
SP Entity IDAudience URI, Audience Restriction, Identifier, Service Provider Entity ID
SP Metadata URLService provider metadata, SP metadata document
Login URLIdP SSO URL, SAML endpoint, SSO service URL, HTTP-POST binding location
IssuerIdP Entity ID, IdP Issuer, Identity Provider Issuer
Certificate (Base64)Signing certificate, X.509 certificate, PEM certificate

Step 1 — Create the connection in Devs.ai​

  1. Go to Organization Settings and select Enterprise SSO (https://devs.ai/org-enterprise-sso).
  2. Select Add Connection.
  3. Enter a Connection Name that identifies your provider, for example OneLogin SSO.
  4. Set Identity Provider to Custom SAML. This cannot be changed later, so if you are actually using Okta, Entra ID, or Google Workspace, use the dedicated guide for that provider instead.
  5. Under Domains, add each email domain you want routed through your provider, for example acme.com. Press Enter or type a comma after each one.
  6. Leave the identity provider fields empty for now — you will fill them in at Step 4 — and select Create Connection.

Step 2 — Give your provider the service provider values​

Open the connection and find the Service Provider Configuration section. Copy these values into your provider's SAML application:

  • ACS URL — where the SAML response is sent.
  • SP Entity ID — the audience the assertion is intended for.
  • SP Metadata URL — if your provider can import service provider metadata, use this and skip the other two.

Also configure, if your provider asks:

  • Name ID format — email address.
  • Name ID value — the user's primary email address.
  • Signing — sign the SAML assertion or response. Devs.ai validates the signature against the certificate you supply in Step 4.
  • Binding — HTTP-POST for the assertion consumer service.

Step 3 — Configure the claims your provider sends​

Devs.ai expects these four claim names by default for Custom SAML:

Devs.ai fieldExpected claim nameShould contain
User IDidA stable identifier for the user
Email addressmailThe user's primary email address
First namefirstNameGiven name
Last namelastNameFamily name

You have two options, and either is fine:

  • Match the defaults — configure your provider to emit attributes named exactly id, mail, firstName, and lastName. Names are case-sensitive.
  • Match your provider — leave your provider's existing claim names alone and edit the four Attribute mapping fields on the connection page to match them. For providers that emit standard SAML URIs, that often means values like http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Pick a User ID claim that does not change when someone's name or email changes — an internal directory ID or employee ID is ideal. If your provider does not expose one, the email address is an acceptable fallback.

Step 4 — Send the provider details back to Devs.ai​

If your provider publishes a metadata URL (recommended)

Paste it into App Federation Metadata Url and select Save Changes. It must be publicly reachable and start with https://. Endpoints and the signing certificate are then read from your provider, so certificate rotations do not break sign-in.

If your provider exports a metadata file

Select Upload file under Federation Metadata XML and choose the exported XML, then select Save Changes. An uploaded file is a snapshot — you will need to upload it again after a certificate rotation.

If your provider only gives you individual values

Select Use manual configuration and enter:

  • Login URL — your provider's SAML sign-in endpoint, using the HTTP-POST binding.
  • Issuer — your provider's entity ID.
  • Certificate (Base64) — select Upload file and choose the signing certificate. .crt, .cer, .pem, and .txt files are accepted. It must be Base64-encoded, which is the same as PEM format: a block of text between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----.

Step 5 — Grant access in your provider​

Assign the users, groups, or policies that should have access to the SAML application. Someone who is not entitled in your provider cannot sign in, even if their email domain matches your connection.

Step 6 — Test and enable​

  1. On the Devs.ai connection page, confirm the header shows the Active badge. If it shows Inactive, select Enable.
  2. Have one administrator sign out and sign back in with their work email address. They should be redirected to your provider.
  3. After signing in, check that their name and email are correct in Devs.ai. If something is missing, revisit the claims in Step 3.
  4. Once the test passes, announce the change and roll out to the rest of your organization.

Troubleshooting​

The assertion is rejected as invalid Almost always a mismatch in one of three things: the audience (your SP Entity ID), the destination (your ACS URL), or the signature (your Certificate). Compare all three against the connection page, using the copy buttons rather than retyping.

Signature validation fails Confirm your provider signs the assertion or the response, and that the certificate you uploaded is the current signing certificate — not an encryption certificate, and not an expired one from a previous rotation.

The assertion has expired SAML assertions are short-lived and validated against a time window. If your identity provider's clock has drifted, sign-in fails intermittently. Make sure your provider's host has working time synchronization.

Members appear with a missing or wrong name Your claim names and the Attribute mapping fields do not agree. Inspect an actual assertion — most providers offer a SAML tracer or test tool — and copy the exact attribute names into the mapping fields.

Nothing happens after entering an email address Check that the connection is Active and the domain is listed under Domains. If your members use subdomain email addresses, turn on Allow subdomains.

⌘J