Setting up Single Sign-On (SSO)

📢Note: This article is only for the use of customers participating in the Single Sign-On Pilot Program. Your dashboard will not have accurate permissions if you are not part of this program. Reach out to your Customer Success Manager if you have additional questions.

Single sign-on lets your team sign in to GovDocs through your own identity provider (IdP) — like Microsoft Entra — using your existing company credentials. Once enabled, users whose email domain matches your configuration are routed to your IdP to sign in.

Setting up SSO has three stages, and the SSO Settings page guides you through them:

Configure — register a SAML application in your identity provider and save its metadata URL in GovDocs.
Verify — run a test sign-in to confirm the connection works.
Enable — turn SSO on for your company once the test passes.

Saving your configuration does not turn SSO on. You configure, test, and only then enable — so you can set everything up safely before it affects your users.

Before you begin

You'll need:

The SSO Manager role in the GovDocs portal, your Customer Success Manager can grant this.
Administrator access to your identity provider.
Permission to create a SAML / enterprise application in your IdP.

SSO is configured per company. Open SSO Settings from your account menu to begin.

Step 1 — Configure your identity provider

Values you'll provide to your IdP

Your SSO Settings page shows two values your identity provider needs, labeled exactly as Microsoft Entra's form asks for them:

Identifier (Entity ID)
Reply URL (Assertion Consumer Service URL)

Copy each with its copy button, you'll paste them into Entra in the next step.

Create the application in Microsoft Entra

In the Microsoft Entra admin center, go to Enterprise applications → New application → Create your own application. Choose "Integrate any other application you don't find in the gallery," name it (e.g. "GovDocs"), and create it.
Open the app's Single sign-on section and choose SAML.
Edit Basic SAML Configuration and paste in the Identifier (Entity ID) and Reply URL values from your SSO Settings page — the field names match. Save.
Confirm the email claim. Entra sends each user's email by default (the emailaddress claim mapped to user.mail ). Make sure your users have an email address populated in Entra — GovDocs uses it to identify them.
Under Users and groups, assign the people who should sign in — and include yourself, so you can run the test sign-in in the next step. Only assigned users can sign in through SSO; unassigned users are blocked by Entra.
In the SAML Certificates section, copy the App Federation Metadata URL.

Save it in GovDocs

Back on the SSO Settings page, paste the App Federation Metadata URL into the SAML metadata URL field and Save.

The metadata URL must be a publicly accessible HTTPS URL. A URL that only works inside your corporate network or VPN won't work, because GovDocs fetches it from the internet.

Click Test Sign-In. A window opens and walks through a real sign-in against your IdP — you'll sign in as yourself.

If it passes, you'll see a confirmation and the Enable button becomes available.
If it fails, the message tells you what went wrong. See Troubleshooting below.

Testing doesn't affect your users — nobody is signed in or switched to SSO by a test. A passing test confirms your IdP integration works; it doesn't guarantee every individual user can sign in (for example, a user whose email domain isn't in your configuration will still be blocked).

Step 3 — Enable SSO

Once your test passes, click Enable. From that point, users whose email domain matches your configuration sign in through your identity provider.

To turn SSO back off, click Disable — those users fall back to GovDocs password sign-in.

Email domains

GovDocs automatically detects your company's email domains from your existing users and shows them on the SSO Settings page. Public providers (gmail.com, outlook.com, etc.) are excluded.

Configured domains route to your IdP once SSO is enabled.
Newly detected domains appear when a user with a new domain joins; click Add to configuration to include them.

The email your IdP sends for each user must end in one of your configured domains, or that sign-in is rejected.

Troubleshootin

What you see	Likely cause	Fix
Microsoft says "you can't access this application" / "not assigned" during the test	The user isn't assigned to the enterprise app in Entra	Assign the user (and yourself) under Users and groups
Sign-in succeeds at Microsoft but GovDocs rejects you	The email your IdP sent doesn't match a configured domain	Confirm the email claim sends an address ending in one of your configured domains. Guest accounts can send an unexpected domain — map the claim to the user's real email
GovDocs says the metadata URL can't be validated or reached	The URL isn't publicly accessible, or isn't valid IdP metadata	Use the public App Federation Metadata URL over HTTPS; internal/VPN-only URLs won't work
The test window opens then closes with "test canceled"	The popup was closed before finishing, or you weren't assigned to the app	Re-run the test; if it keeps happening, check your assignment in Entra
The test window is blocked from opening	Browser popup blocker	Allow popups for the GovDocs site and try again
Do I need to redo this when my signing certificate rotates?	—	No. GovDocs re-reads your metadata URL automatically, so certificate rotations are picked up with no action from you

Still need help?

Contact your Customer Success Manager.

Notes

Certificate rotation is automatic — GovDocs periodically re-reads your metadata URL, so when your IdP rotates its signing certificate, SSO keeps working.
SSO is per company. Each company configures its own IdP.
When SSO is disabled, users with matching domains return to password sign-in.