How does Single Sign-On (SSO) work on Vome?
Overview
Single Sign-On lets your administrators reach Vome through the login your organization already controls, instead of keeping a separate Vome password.
Vome's SSO is SAML-based and covers administrator authentication. Your identity provider vouches for who someone is, and Vome lets them in.
SSO is available on the Ultimate plan.
Why use it
One set of credentials. Administrators sign in with the account they already use everywhere else.
Offboarding actually works. When someone leaves and IT disables their directory account, their route into Vome closes with it.
Your password policy applies. Length, rotation, multi-factor, conditional access, all of it is enforced by your identity provider rather than duplicated here.
It satisfies IT review. For many organizations, SSO is the condition of approving a new system at all.
Which identity providers are supported
Vome supports three, each with its own setup guide:
Microsoft Entra ID, formerly Azure Active Directory. This is what the Microsoft Azure card in Integrations & Apps points at. Setup guide
Microsoft ADFS, for organizations running Active Directory Federation Services on their own servers. Setup guide
JumpCloud, currently in beta. Setup guide
What SSO does not do
This is the part worth reading before you plan the rollout.
It does not create accounts. An administrator must already exist in Vome before they can sign in through SSO. If the email address your identity provider returns does not match an existing Vome admin, the login fails.
It does not sync your directory. There is no user import and no SCIM provisioning. Adding and removing administrators in Vome stays a separate step.
It is for administrators. It is not the login route for the wider group of people using your organization page.
How to set it up
The exact fields differ by provider, so follow the guide for yours. The shape is the same in all three cases:
In Vome, go to Settings and open the SSO section, then choose your provider.
Copy the Identifier (Entity ID) and Reply URL (ACS URL) that Vome gives you.
In your identity provider, create a SAML application and paste those two values in.
Send the provider's details back to Vome. For Entra ID that is the login URL, certificate, tenant ID, client ID and client secret. For ADFS and JumpCloud it is the federation metadata XML and the signing certificate.
Click Verify configuration. Vome checks the values are well formed.
Click Test SSO and complete a real login through your provider.
Enforcing SSO, and the one setting not to skip
Enforcement is optional. Leave it off and administrators can use either a Vome password or SSO. Turn on Require SSO for all users and the password route closes.
Common problems
Login succeeds at the provider, then fails at Vome. The email address coming back does not match a Vome administrator. Check the account exists in Vome and that the provider is sending the right email through NameID.
Certificate errors. The certificate has to be Base64 encoded and uploaded unmodified.
Stale metadata. If you exported metadata before saving the application at the provider, export it again and re-upload.
Client ID or secret needs changing. Once stored, those values are hidden and cannot be read back. Contact support if they need updating.
SSO and two-factor authentication
They solve different parts of the same problem and can coexist. If your identity provider already enforces multi-factor authentication, that requirement applies to anyone signing in to Vome through SSO.
Summary
SAML-based Single Sign-On for administrators, on the Ultimate plan.
Microsoft Entra ID, Microsoft ADFS and JumpCloud (beta) are supported.
Administrators must already exist in Vome. SSO authenticates, it does not provision.
Set it up in Settings then SSO, verify, then test with a real login.
Always configure an excluded user before enforcing SSO.