Single sign-on
Single sign-on is part of the Enterprise plan. It is set up by an admin under Settings, Security, in four steps: give your identity provider Vercatus’s details, verify a domain, test the sign-in, turn the connection on. Enforcing it is a fifth, for an owner.
1. Verify a domain
Section titled “1. Verify a domain”Sign-ins are routed by the domain of the address, so a connection works only for domains the workspace has
verified. Under Domains, add the domain (acme.com); publish the TXT record it shows at your DNS provider and
press Verify:
| Type | Name | Value |
|---|---|---|
TXT |
the domain itself (some providers want @) |
vercatus-domain= followed by the workspace’s token |
This is a different record from the one that verifies a site. DNS changes can take a few minutes to show. Once verified, the record can stay; it is not checked again. A domain belongs to one workspace; a workspace can verify up to 20.
2. Connect your identity provider
Section titled “2. Connect your identity provider”Under Single sign-on, add a connection (up to five per workspace):
| Provider | What you enter |
|---|---|
| Google Workspace | client ID and secret; sign-ins must come from the Workspace domain |
| Microsoft Entra ID | the directory (tenant) ID, and the application (client) ID and secret |
| Okta | the issuer URL, and the client ID and secret |
| Other OpenID Connect | the issuer URL (it must publish a discovery document), and the client ID and secret |
| SAML 2.0 (ADFS, JumpCloud, OneLogin, PingFederate and others) | the IdP sign-in URL, the IdP entity ID (optional) and the IdP signing certificate |
For OpenID Connect, register the sign-in redirect URI the drawer shows with your provider; Vercatus asks for
openid email profile. For SAML, give your IdP the assertion consumer service (ACS) URL (HTTP-POST) and the
service provider entity ID the drawer shows, which is also the URL of Vercatus’s metadata. The Name ID should be
the email address, and assertions must be signed. Sign-in starts from Vercatus (SP-initiated). A client secret is
stored encrypted and never shown again; an expired certificate is refused.
3. Test the sign-in
Section titled “3. Test the sign-in”Test sign-in runs the whole flow against your provider without signing anyone in. The result page shows what would happen to that person (a member signed in, a new person joining with the default role, or refused) and every claim the provider sent. A connection can be turned on only after a test succeeded and a domain is verified.
4. Turn it on
Section titled “4. Turn it on”With the connection on, sign-in is email-first: a person enters their address, and if its domain is verified by the workspace they are offered Continue with single sign-on, with Use my password instead beside it until the domain is enforced.
Just-in-time provisioning is on by default: someone on a verified domain without an invitation joins on their first sign-in with the connection’s default role (admin, analyst or viewer; the default is viewer). Joining with a role that takes a seat needs a free seat; with none free, the person joins as a viewer and the audit log says so. With provisioning off, only invited people and existing members get in.
5. Enforce it
Section titled “5. Enforce it”An owner can require single sign-on per verified domain. Password sign-in and password sign-up are then refused for that domain, including owners, and so are Continue with Google and Continue with Microsoft; the sign-in page sends those addresses straight to the provider. Enforcement needs an enabled connection that has signed someone in (a successful test counts), so nobody is locked out by a connection that never worked. Turning off or deleting the last enabled connection lifts enforcement, and the audit log records it. API keys keep working. The owner also sets how long a session lasts, from 8 hours to 30 days.
If the plan stops including single sign-on, routing stops and people sign in with their email and password.
Records
Section titled “Records”Adding and verifying domains, every connection change and test, enforcement and each single sign-on sign-in are in the audit log.