The average professional at a mid-size firm manages 27 separate application logins. They know they should use unique, strong passwords for each one. They know they should not reuse passwords. They know that "Password1!" with a capital P and an exclamation mark does not actually fool anyone. And yet, when the deadline is looming and the password manager is not auto-filling correctly, they type the same password they use for everything, log in, and get on with their work.
This is not a character flaw — it is a predictable response to unreasonable cognitive load. The problem is systemic: every new application a firm adopts adds another password to manage. As firms have adopted cloud tools over the past decade, the number of credentials in play has exploded, and with it, the attack surface. Password reuse, phishing, and credential stuffing attacks are not abstract threats. They are the leading cause of data breaches in professional service firms, and the vector is almost always a compromised credential for one application that was reused across others.
What SAML Single Sign-On Actually Does
SAML (Security Assertion Markup Language) is an open standard that enables one trusted identity system — your Identity Provider (IdP) — to assert who a user is to other applications, called Service Providers. When a user signs into Middledoc via SAML SSO, they are not entering a Middledoc password. They are authenticating with their corporate identity provider (Okta, Azure Active Directory, or Google Workspace), which then tells Middledoc "this is James Chen, he belongs to your organization, he has these roles" — and Middledoc grants access accordingly.
The practical result: your team members have one set of credentials for everything. They log into Okta (or Azure or Google) in the morning — ideally with MFA — and that single authentication carries them through their entire day across every SAML-connected application. Middledoc, Salesforce, Slack, your document management system — all accessed without a separate login.
Why Professional Services Firms Need SSO More Than Most
Professional service firms — accounting, law, HR consulting, healthcare — handle sensitive client data that is subject to regulatory requirements: HIPAA, SOC 2, various state data protection laws, and client contractual obligations. These regulations increasingly require firms to demonstrate not just that they have security controls, but that those controls are consistently enforced.
Password-based authentication is inherently inconsistent. Some employees use strong passwords; others do not. Some use MFA; others skip it. When a team member leaves the firm, their accounts across a dozen different applications need to be manually deprovisioned — and in practice, this step gets missed. A terminated employee's credentials can remain active for weeks or months, representing a serious security and compliance risk.
SAML SSO solves all of these problems at once. MFA enforcement happens at the IdP level, so it applies to every connected application without configuration at each one. When a team member is offboarded, deactivating their account in your IdP immediately revokes access to every SAML-connected application. No manual deprovisioning. No missed accounts. No access gaps.
Middledoc's SAML Implementation
Middledoc supports SAML 2.0 with the three major identity providers used by professional service firms: Okta, Microsoft Azure Active Directory (now Entra ID), and Google Workspace. The configuration process follows the standard SAML metadata exchange: you provide Middledoc with your IdP's metadata URL, and Middledoc provides the service provider metadata that you enter into your IdP configuration. This exchange takes about 15 minutes and does not require any code.
For Okta specifically: navigate to your Okta admin dashboard, add a new SAML 2.0 application, and use Middledoc's provided ACS URL and Entity ID. Copy the Okta metadata URL back into Middledoc's SSO settings. Assign the application to the appropriate Okta groups. Done. For Azure AD, the process is equivalent via the Enterprise Applications section in the Azure portal. For Google Workspace, it goes through the Custom SAML Apps section in the Google Admin console.
Just-in-Time Provisioning: No More Manual User Setup
One of the most operationally significant aspects of Middledoc's SSO implementation is Just-in-Time (JIT) provisioning. When a team member signs in via SSO for the first time, Middledoc automatically creates their account using the attributes provided by the IdP — name, email, department, and role. No manual user creation required. No invitation emails to send. No waiting for IT to set up accounts.
The role assigned to the new account is determined by IdP group membership. If you have a group called "Middledoc_Admins" in Okta, members of that group are provisioned as administrators in Middledoc. Members of "Middledoc_Members" are provisioned as standard members. This means your IT team controls access and roles entirely through your existing IdP — no Middledoc admin interface needed for day-to-day user management.
Enforcing SSO: Blocking Password-Based Access
Connecting SSO is only half the security story. The other half is enforcing it. If team members can still log in with a username and password, SSO becomes an option rather than a requirement — and you lose the consistent enforcement that makes SSO valuable for compliance.
Middledoc's Firm plan includes an "Enforce SSO" setting that blocks all non-SSO authentication for your domain. When enabled, any team member with a @yourfirm.com email address must authenticate via SSO. Attempts to log in with a password return an error directing them to use SSO instead. This can be applied to the entire firm or scoped to specific email domains — useful for firms where one domain requires SSO enforcement and others (like contractors) do not.
Meeting Compliance Requirements
For firms pursuing SOC 2 Type II certification, HIPAA compliance, or meeting client security questionnaires, SSO enforcement is often a required control. The relevant controls typically require: centralized authentication management, MFA for all users, documented access provisioning and deprovisioning procedures, and the ability to revoke access promptly upon termination.
Middledoc's SAML SSO implementation satisfies all four requirements directly. Your IdP (Okta, Azure, or Google Workspace) provides centralized authentication management. MFA enforcement happens at the IdP level and applies to all Middledoc access automatically. JIT provisioning provides documented, automated provisioning. IdP deactivation immediately revokes Middledoc access for deprovisioning.
When completing a security questionnaire about Middledoc — for a client audit, a vendor security review, or your own SOC 2 preparation — you can document a consistent, auditable authentication posture rather than a patchwork of policies. For many firms, this is the tipping point: SSO is not just a convenience feature, it is a compliance requirement that is easier to meet with the right tooling in place.
Getting Started with SAML on Middledoc
SAML SSO is available on Middledoc's Firm plan. If you are evaluating whether the Firm plan is right for your firm, SAML support is one of several enterprise features — along with QuickBooks integration, advanced analytics, and unlimited documents — that make it the right choice for teams of five or more people handling sensitive client data.
Setup takes less than 30 minutes and does not require developer resources. The configuration guide in Middledoc's help documentation walks through each identity provider step by step, with screenshots from current versions of Okta, Azure AD, and Google Workspace. If you run into any issues, Middledoc's support team can walk through the configuration with you — SAML setup is a supported onboarding step, not a self-serve edge case.