DocsAccounts & billing
Single sign-on
Let your staff open the RubySig portal with your own identity provider — Okta, Microsoft Entra ID, Google — instead of a separate password.
Updated August 30, 2026
The portal supports SAML 2.0 single sign-on. Once it is on, anyone at your organization who signs in with SSO lands in your company's portal automatically, with the access their role grants, and there is no RubySig password to manage or leak. Password sign-in keeps working alongside it.
Setting it up is two halves: you add RubySig as an application in your identity provider, then RubySig registers that provider for your email domains.
Note: SSO is for signing in to the portal. It has nothing to do with mail flow — the relay never sees your directory credentials.
1. Add RubySig in your identity provider
Create a new SAML 2.0 application and give it these values. They are the same for every customer.
| Setting | Value |
|---|---|
| Single sign-on URL (ACS URL) | https://efbslyljyaaheirbcxhk.supabase.co/auth/v1/sso/saml/acs |
| Audience URI (SP Entity ID) | https://efbslyljyaaheirbcxhk.supabase.co/auth/v1/sso/saml/metadata |
| Name ID format | EmailAddress |
| Application username |
Add three attribute statements so the portal can name people correctly:
| Name | Value |
|---|---|
email |
the user's email address |
firstName |
given name |
lastName |
family name |
Assign the application to the people, or the group, who should reach the portal. Then copy the application's metadata URL — in Okta it is under Sign On → SAML Signing Certificates → Actions → View IdP metadata; in Entra ID, App Federation Metadata Url; in Google, download the metadata file.
Tip: Assigning the app decides who can sign in. What they can do once inside is set by their role in the portal — SSO does not grant admin rights on its own.
2. Send us the metadata
Send the metadata URL (or the downloaded XML) and the email domains it should cover to your RubySig contact. We register the provider against those domains — it takes a few minutes, and there is nothing to change on your side afterwards.
We can only register domains that are already verified on your account. If you need a new domain covered, add it to your mail platform first so it appears on your Setup page.
3. Sign in
On the portal sign-in page, choose Sign in with SSO and enter a work email address. The portal reads the domain, hands the browser to your identity provider, and returns to your company's portal once the identity provider says yes.
The first time each person signs in, the portal creates their account and attaches it to your company from the email domain. They see the same thing an invited user would.
Turning it off
Ask us to remove the provider. Existing SSO accounts stay, but can no longer sign in through the identity provider; anyone who also had a password sign-in keeps it. Unassigning the application in your identity provider has the same effect for one person at a time, immediately.
Troubleshooting
| What you see | Cause | Fix |
|---|---|---|
| "No SSO provider for this domain" | The domain has not been registered with us yet, or the address entered was a personal one. | Use a work address on a registered domain; check with your RubySig contact that registration is complete. |
| The identity provider shows an error before returning | The ACS URL or Entity ID in the app does not match the table above, or the person is not assigned to the app. | Compare the values character for character; assign the person. |
| Signed in, but the portal shows no company | The email domain on the identity is not one of your verified domains. | Add the domain to your mail platform (it appears on the Setup page after the next sync), then sign in again — or ask us to attach the account. |