Skip to main content
CloudCruise supports SAML 2.0 Single Sign-On (SSO), so your team signs in to the dashboard with your own identity provider (IdP) instead of a CloudCruise password. You can also require SSO for everyone on your email domain, centralizing access in your IdP and turning off password sign-in.
SAML SSO is part of the Enterprise plan and is configured per organization by an organization owner. If you don’t see the Authentication settings, contact CloudCruise to enable it.

​
How it works

SSO is set up in two steps, both from Organization Settings → Authentication:
  1. Verify your domain — prove you own the email domain your team uses (e.g. acme.com) by adding a DNS TXT record.
  2. Attach a SAML configuration — paste your IdP’s metadata (Entity ID, SSO URL, signing certificate) onto the verified domain.
Once configured, anyone with an email on that domain can authenticate with SSO. Access to an organization or workspace is still controlled by CloudCruise membership and invites. Optionally, turn on Require SSO to block password sign-in and sign-up for the domain entirely. Any SAML 2.0–compliant identity provider works, including:
  • Okta
  • Microsoft Entra ID (Azure AD)
  • Google Workspace
  • OneLogin
  • Ping Identity
  • JumpCloud
  • …and any other SAML 2.0 IdP

​
Before you start

You’ll be moving values back and forth between your IdP and CloudCruise. From CloudCruise, your IdP needs these Service Provider (SP) details:
These Service Provider URLs are the same for every CloudCruise customer — they’re CloudCruise’s hosted SAML endpoint. Point your IdP’s ACS and Audience at them, and send the user’s email address as the SAML Name ID.
From your IdP, CloudCruise needs three values (covered in Step 2):
  • IdP Entity ID — your IdP’s SAML issuer / metadata identifier.
  • IdP SSO URL — the IdP login endpoint (must be HTTPS).
  • IdP signing certificate — the IdP’s x509 public certificate, in PEM format.

​
Step 1: Verify your domain

1

Open Authentication settings

Go to your organization’s Settings → Authentication page. (This link resolves to your active organization automatically.)
2

Add your email domain

Under Verified domains, enter the domain your team signs in with (for example acme.com) and click Add domain. A verification dialog opens automatically.
3

Publish the DNS TXT record

Add the following record at your DNS provider (the dialog shows the exact values with copy buttons):The token is generated per domain — copy it from the dialog rather than from this page.
4

Verify

Click Start verification. CloudCruise checks DNS every 15 seconds for up to 15 minutes (you can also click Check now). Once the record is found, the domain flips to Verified.
DNS changes can take anywhere from a minute to a few hours to propagate. If verification keeps failing, the dialog tells you exactly what it found at the hostname — e.g. a stale cc-sso-verify= record or no record at all.
A domain can only be verified by one organization. Multiple organizations can have a pending claim on the same domain, but only the first to verify it via DNS takes ownership.

​
Step 2: Add your SAML configuration

First create a SAML application in your IdP using the Service Provider details above, then bring the IdP’s values back into CloudCruise.
1

Create the SAML app in your IdP

In your identity provider, create a new SAML 2.0 application and set:
  • ACS URL → https://hrcczpkvvknatvtuwksw.supabase.co/auth/v1/sso/saml/acs
  • Audience / SP Entity ID → https://hrcczpkvvknatvtuwksw.supabase.co/auth/v1/sso/saml/metadata
  • Name ID → the user’s email address, format emailAddress
Assign the app to the users or groups who should be allowed to authenticate with CloudCruise. They still need CloudCruise organization and workspace membership to access your team’s workspaces.
2

Copy your IdP's metadata values

From the IdP’s SAML metadata (or app settings), collect:
  • IdP Entity ID (e.g. https://idp.acme.com/metadata)
  • IdP SSO URL — the HTTPS sign-on endpoint (e.g. https://idp.acme.com/sso)
  • Signing certificate in PEM form, including the -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- lines
3

Create the configuration in CloudCruise

Back on the Authentication page, under SAML configuration:
  1. Choose the verified domain from Step 1.
  2. Paste the IdP Entity ID, IdP SSO URL, and IdP Certificate (PEM).
  3. Click Create configuration.
CloudCruise validates the values and registers the provider with its hosted SAML endpoint.
4

Test the login

Open the login page, choose Sign in with SSO, and enter a work email on the configured domain. You should be redirected to your IdP and, after authenticating, returned to CloudCruise signed in.
The IdP SSO URL must use HTTPS, and the certificate must be a valid PEM-encoded x509 certificate (starting with -----BEGIN CERTIFICATE-----). The dashboard rejects values that don’t meet these requirements.

​
Signing in directly from your IdP (optional)

Most identity providers offer a dashboard where users can click an app tile to launch straight into a connected app — Okta calls this an app tile, Entra ID and OneLogin call it a bookmark application. If you try pointing that tile directly at CloudCruise’s SAML app, users are redirected to the CloudCruise login page instead of being signed in.
This is a limitation of the IdP-initiated SAML flow itself, not a CloudCruise-specific bug: an app tile POSTs an unsolicited SAML assertion straight to CloudCruise’s SAML endpoint, with none of the request state CloudCruise normally sets up first. To keep sign-in secure, that state is required, so an unsolicited assertion can’t complete a login.
To get the same one-click experience safely, point the tile at CloudCruise’s SSO initiation URL instead of directly at the SAML app. CloudCruise starts the login itself from there, so the request state exists and the sign-in completes normally:
Replace <your-verified-domain> with the domain you verified in Step 1 (for example acme.com).
1

Create a bookmark app in your IdP

In your IdP, create a bookmark or link application (not a SAML application) with the URL above as its target. In Okta: Applications → Create App Integration → Bookmark App.
2

Assign it to your users

Assign the bookmark app to the same users or groups as your SAML app. Clicking it now runs the normal SSO login and lands them in CloudCruise signed in.
Not every IdP has a bookmark-app concept (for example, Auth0 doesn’t). In that case, just share the SSO initiation URL above directly — as a link on your intranet, in a password manager, or as a browser bookmark. It works the same way either way.

​
Requiring SSO (enforcement)

Each SAML configuration has a Require SSO toggle: Enforcement is applied both in the CloudCruise sign-in flow and deep in the auth layer, so it can’t be bypassed by going straight to the password form.
Turn enforcement on only after you’ve confirmed SSO login works end-to-end. CloudCruise also enforces this at the database level: Require SSO cannot be turned on until at least one organization Owner has actually signed in via SSO and linked their account, which prevents the classic case of enforcement being flipped on before anyone can use SSO yet. This doesn’t protect against every failure mode — if your IdP breaks later (e.g. a certificate rotates) while enforcement is already on, you can still end up temporarily locked out. Leave it off while testing, then flip it on.

​
User provisioning

CloudCruise uses just-in-time provisioning. When a user signs in through SSO for the first time, an account is created automatically from the email address in the SAML assertion — there’s no separate import step. The email comes from the SAML Name ID (emailAddress format), which is why your IdP must send it there. Just-in-time provisioning creates the CloudCruise user account and profile only. It does not automatically add the user to your organization or to every workspace. To give a user access, invite them to your organization from CloudCruise. When they accept the invite, they’re added as an organization Member and as a Member of the organization’s existing workspaces. New workspaces can also be created with existing organization members added automatically, or workspace access can be managed separately.
If someone already has a CloudCruise account under the same email — for example, they signed up with a password before your organization set up SSO — signing in via SSO does not automatically merge into that existing account. SAML identities are deliberately never auto-linked to other accounts, for security reasons. Instead, CloudCruise detects the match and prompts the user to link the two accounts: if the existing account already has organization access, linking is required before they can continue; otherwise it’s an optional prompt they can act on whenever they choose. Until they link, the two accounts stay fully separate.
For most providers the default mapping (Name ID → email) is all you need. If your IdP can only send email as a custom attribute claim, contact support — a custom attribute mapping can be applied to your configuration.

​
Identity provider quick reference

The exact labels differ per provider, but the mapping is always the same.
  1. Applications → Create App Integration → SAML 2.0.
  2. Single sign-on URL → https://hrcczpkvvknatvtuwksw.supabase.co/auth/v1/sso/saml/acs
  3. Audience URI (SP Entity ID) → https://hrcczpkvvknatvtuwksw.supabase.co/auth/v1/sso/saml/metadata
  4. Name ID format → EmailAddress; Application username → Email.
  5. Finish, then open Sign On → View SAML setup instructions to grab:
    • Identity Provider Issuer → IdP Entity ID
    • Identity Provider Single Sign-On URL → IdP SSO URL
    • X.509 Certificate → paste as the PEM certificate

​
Managing and removing configurations

From the Authentication page you can:
  • Toggle Require SSO on or off at any time.
  • Delete a SAML configuration — users on that domain can no longer sign in via SSO (delete this before removing the domain).
  • Delete a verified domain — only allowed once its SAML configuration has been removed.

​
Troubleshooting

Confirm the TXT record is on the exact host _cloudcruise-sso-verification.<your-domain> and the value matches cc-sso-verify=<token> from the dialog. The verification dialog reports what it actually found — a stale token, a non-CloudCruise record, or nothing yet. Allow time for DNS propagation and use Check now to retry.
The email’s domain has no SAML configuration, or you entered a domain that isn’t verified. Make sure the domain is Verified and has a SAML configuration attached, and that the user’s email domain exactly matches.
Double-check the ACS URL and SP Entity ID in your IdP exactly match the values above, and that the IdP sends the user’s email as the Name ID in emailAddress format. A mismatched audience or missing email is the most common cause.
This happens when the IdP tile points directly at the SAML app (an IdP-initiated login), which CloudCruise’s SAML endpoint can’t complete. See Signing in directly from your IdP — point the tile at the SSO initiation URL instead.
The IdP SSO URL must be HTTPS, and the certificate must be a PEM block beginning with -----BEGIN CERTIFICATE-----. Copy the full certificate including the header and footer lines.
CloudCruise prevents the most common cause of this: enforcement can’t be turned on until an organization Owner has already linked their account via SSO, so there’s always at least one Owner able to sign in. If you’re still locked out — for example, your IdP configuration broke after enforcement was already on — contact support to temporarily disable enforcement so you can fix the IdP settings.

​
Security notes

  • CloudCruise validates each SAML assertion against the signing certificate you provide — rotate it in your IdP and update the configuration if it changes.
  • Enforcement blocks the password path server-side, not just in the UI, so it cannot be bypassed.
  • SSO is scoped to your organization for configuration and enforcement. Workspace access is still determined by CloudCruise workspace membership.
  • All configuration changes (created, updated, enforcement toggled, deleted) are recorded in an audit log.