Skip to main content

Enterprise SSO overview

Enterprise SSO lets your members sign in to Devs.ai with the same company credentials they already use everywhere else. You connect your identity provider (IdP) once using SAML 2.0, and from then on anyone with an email address at your domain is authenticated by your IdP instead of a Devs.ai password.

That means your existing identity rules — password policy, conditional access, device checks, offboarding — apply automatically. When someone leaves your company and you deactivate them in your identity provider, they lose access to Devs.ai too.

📝 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. Once it is enabled, your organization admins can configure and manage the connection themselves from Organization Settings.

Choose your identity provider​

Each guide below walks through the full setup, on both sides, for one provider:

Picking a provider in Devs.ai pre-fills sensible defaults, most importantly the claim names used for attribute mapping. You can adjust every value afterwards.

How it works​

  1. A member enters their email address on the Devs.ai login page.
  2. If the address belongs to a domain covered by your active connection, Devs.ai sends the member to your identity provider instead of asking for a password.
  3. The member authenticates with your identity provider, under whatever policies you enforce there.
  4. Your identity provider returns a signed SAML assertion, and the member lands in Devs.ai, already signed in.

Members never type a Devs.ai password, and you never have to manage one for them.

Before you begin​

  • Enterprise SSO must be enabled for your organization. If you do not see Enterprise SSO in Organization Settings, contact your Devs.ai representative.
  • You need edit access to Organization Settings. Members with view-only access can see the configuration but cannot change it. See User permissions.
  • You need administrator access to your identity provider so you can create a SAML application and read its metadata.
  • Have your email domains ready — the domains whose users should be routed to your identity provider, for example acme.com.

Set aside about 30 minutes. Configuration moves back and forth between Devs.ai and your identity provider, because each side needs values generated by the other.

What you configure​

Whichever provider you use, a connection is made up of the same pieces. The provider guides tell you exactly where each value comes from.

Basic configuration​

  • Connection Name — A label for your own reference, for example Corporate SSO.
  • Identity Provider — Okta, Google Workspace, Microsoft Entra ID, or Custom SAML. This cannot be changed later, so pick carefully.
  • Domains — One or more email domains. Press Enter or type a comma to add each one. Users with an email address at these domains are authenticated through this connection.

Service provider configuration​

These three values are generated by Devs.ai and shown on the connection page, each with a copy button. You paste them into your identity provider:

ValueTypically called in your identity provider
ACS URLAssertion Consumer Service URL, Single sign-on URL, or Reply URL
SP Entity IDAudience URI, Identifier, or Entity ID
SP Metadata URLService provider metadata — some providers can import everything from this one URL

Identity provider configuration​

These values come from your identity provider. Use whichever method your provider makes easiest — you only need one:

  • Metadata (recommended) — Paste an App Federation Metadata Url (it must start with https://), or upload the Federation Metadata XML your provider exported. Endpoints and the signing certificate are then read directly from your provider.
  • Manual configuration — Select Use manual configuration and enter the Login URL (your provider's SAML sign-in endpoint), the Issuer (your provider's entity ID, labeled Microsoft Entra Identifier for Entra ID), and the Base64-encoded Certificate.

You can switch between the two at any time. Devs.ai keeps only the set of values you saved last.

Attribute mapping​

Attribute mapping tells Devs.ai which claims in the SAML assertion hold each piece of user information: User ID, Email address, First name, and Last name.

Defaults are filled in for the provider you selected, so in most cases you can leave them alone:

FieldOkta, Google Workspace, Custom SAMLMicrosoft Entra ID
User IDidhttp://schemas.microsoft.com/identity/claims/objectidentifier
Email addressmailhttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
First namefirstNamehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
Last namelastNamehttp://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

Either send these claim names from your identity provider, or change these fields to match the names your provider already emits. A mismatch here is the most common cause of failed sign-ins and of members showing up with a blank name.

Connection settings​

  • Sync user attributes — On by default. Each time a member signs in, Devs.ai re-reads the mapped attributes and updates their profile, so name and email changes in your identity provider flow through automatically.
  • Allow subdomains — Lets users on a subdomain of a configured domain (for example eu.acme.com when you configured acme.com) use the same connection.
  • Allow IdP-Initiated flow — Lets members start sign-in from your identity provider's app tile rather than from the Devs.ai login page. This is not recommended: unsolicited assertions are inherently harder to validate, so only enable it if you understand and accept the security trade-off.

Rolling out safely​

Test with one account before you switch your whole organization over:

  1. Confirm the connection shows the Active badge on the connection page.
  2. Have one administrator sign out and sign back in with their work email, and verify they are redirected to your identity provider.
  3. Check that their name and email look correct in Devs.ai — that tells you the attribute mapping is right.
  4. Announce the change to your members, then roll out broadly.

Managing an existing connection​

Everything is managed from Organization Settings → Enterprise SSO.

Editing​

Change the connection name, domains, identity provider configuration, attribute mapping, or settings, then select Save Changes. The Identity Provider cannot be changed after creation — if you are migrating to a different provider, delete the connection and create a new one.

Rotating a certificate is an edit: upload the new Certificate (Base64), or update your metadata URL and save. Do this within your provider's rollover window to avoid sign-in failures. Using a metadata URL avoids the problem entirely, because the new certificate is picked up from your provider.

Disabling temporarily​

Select Disable to switch the connection off without losing its configuration. While it is disabled, members are no longer routed to your identity provider. Select Enable to turn it back on.

Deleting​

Select Delete and type the connection name to confirm. If the connection is active, the dialog tells you how many users currently sign in through it and warns that deleting it immediately blocks those users from signing in via SSO. Deletion cannot be undone, so make sure affected members have another way in first.

What your members see​

For members, SSO makes signing in shorter, not more complicated:

  1. Go to the Devs.ai login page and enter your work email address.
  2. You are redirected to your company's sign-in page.
  3. Authenticate as you normally would.
  4. You return to Devs.ai, signed in.

If your organization also requires two-step verification, members complete that step as well — signing in through an identity provider does not bypass an organization-wide 2FA requirement.

Troubleshooting​

Members are still asked for a password Check that the connection is Active and that the member's email domain is listed under Domains. If they are on a subdomain, turn on Allow subdomains.

Sign-in fails with a SAML error Confirm that the ACS URL and entity ID in your identity provider match the values shown under Service Provider Configuration exactly, with no trailing characters. If you configured the connection manually, verify that the certificate is current and Base64-encoded.

Members appear with a missing or wrong name Your attribute mapping does not match the claims your identity provider sends. Compare the claim names in your provider's SAML application against the values under Attribute mapping.

The metadata URL is rejected The App Federation Metadata Url must be a valid URL using https://. If your provider only exposes metadata behind authentication, download the XML and use Federation Metadata XML instead.

Enterprise SSO does not appear in Organization Settings Either the feature is not enabled for your organization — contact your Devs.ai representative — or your role does not include access to organization settings. See User permissions.

Limitations​

  • SAML 2.0 only — OpenID Connect and WS-Federation enterprise connections are not supported. Any provider that speaks SAML 2.0 works through Custom SAML.
  • One connection per organization — A single SAML connection covers all of your domains. Add every domain you need to that one connection rather than creating several.
  • The identity provider cannot be changed after creation — Switching providers means deleting the connection and setting up a new one.
  • No SCIM provisioning — Directory sync and automated deprovisioning through SCIM are not part of this feature. Mapped attributes are refreshed at each sign-in when Sync user attributes is on.
  • No group or role mapping — Roles and permissions are managed in Devs.ai and are not driven by identity provider groups. See User permissions.
  • No single logout (SLO) — Signing out of Devs.ai does not end the session at your identity provider, and vice versa.
  • First sign-in for a brand-new member — Email-first login recognizes members whose accounts are already linked to your identity provider. A member who has never signed in through it may still be shown the standard password step. If you want every new member routed straight to your identity provider from their very first sign-in, talk to your Devs.ai representative about the rollout options for your organization.
⌘J