Most enterprise software quietly assumes something that is rarely true: that your users all live in one place. In practice, the people who need access to your files come from many directories at once, and good enterprise file management has to support multiple SSO providers — not force you to pick one. This post explains what SSO is, why a single provider is usually not enough, and how Files.com lets each group of users sign in through their own identity system.

First, the terms in plain English. SSO stands for single sign-on: a user logs in once with their company account, and that login grants access to many apps without a separate password for each one. The system that holds those accounts and checks the login is the identity provider, or IdP — Okta, Microsoft Entra ID (formerly Azure AD), Google, and the like. SAML is the standard language an IdP and an app use to pass a "yes, this person is who they say they are" message back and forth. SCIM is the companion standard that keeps the two in sync: when someone is added to or removed from the IdP, SCIM tells the app to create or disable that account automatically. Keep those four in mind and the rest follows.

Now the premise most vendors ignore: your organization's users are not a single, coherent population, and neither is your identity infrastructure. You have employees. Contractors.

Subsidiaries. Trading partners. They each bring their own directory, their own Okta tenant, their own SAML configuration.

Most platforms that support SSO handle this the easy way for the vendor: they make you pick one. One IdP. One canonical user directory. Everyone who touches the platform authenticates through that single system, and anyone who is not in it gets a standalone password the app manages on its own — which is exactly the kind of orphaned credential a security team wants to eliminate.

Why One SSO Is Often the Wrong Answer

The pressure to standardize on a single IdP is real, and it comes from good instincts. Fewer IdP integrations means a smaller attack surface, simpler access audits, and a cleaner story for shutting off access when someone leaves. In an ideal world, every user flows through one authoritative directory.

The enterprise world rarely looks that tidy. Four common cases break the single-IdP assumption:

• Employees and contractors. Many organizations keep full-time employees in one identity system and contractors in another, for legal, HR, and security reasons. Your employees live in Entra ID; your contractors are managed by the staffing agency's Okta. Both groups need SSO access to the file transfer platform, each governed by their own IdP, with no credentials mixed between them.
• Mergers and acquisitions. When two companies combine, they almost never share identity infrastructure. The acquired company has its IdP; the parent has its own. Forcing an immediate migration mid-acquisition is a high-risk project that takes months. You want both directories working at the same time, with a clean cutover when you are ready.
• Partner and vendor access. A trading partner connecting over AS2 or SFTP may prefer to authenticate through their own identity federation instead of managing passwords you issue. That is a reasonable ask, and supporting it builds trust — but their IdP is theirs, not yours.
• Subsidiaries and business units. A large organization often runs subsidiaries or brands with separate IT environments, each with its own directory. The parent wants one set of file infrastructure without forcing an identity consolidation the subsidiary is not ready for.

In each case you need more than one identity provider live at the same time. The question is whether your file management platform supports that cleanly, or makes you flatten your real organization to fit its limits.

How Files.com Supports Multiple SSO Providers

Files.com supports multiple SSO providers on a single site. Okta, Microsoft Entra ID, OneLogin, JumpCloud, Google, Duo, and LDAP can all run side by side, and you can add as many as your deployment needs. Each user is assigned to exactly one provider, and the login page shows that user the right sign-in option.

If you run two tenants of the same IdP — two separate Okta environments from an M&A, say — Files.com handles it through SAML. You configure each as its own SAML instance, distinguished by display name on the login page, and each authenticates against its own IdP configuration independently.

Provisioning is just as flexible. Files.com supports SCIM against multiple providers at once: add a user to your Entra ID tenant and they are created in Files.com automatically; add a contractor to the separate Okta environment and the same thing happens there. For environments that want accounts created on first login without running full SCIM sync, Just-in-Time provisioning does that instead.

You can also mix methods. Some users sign in through one SSO, some through another, and some through a Files.com-managed password — useful for external collaborators or legacy service accounts that do not exist in any IdP.

One caveat to plan around: each user account is tied to a single authentication method. If the same person needs access under two different IdPs — common during an M&A transition — you create two accounts for them. That is a minor inconvenience, and for most teams it is more than offset by the flexibility of never having to consolidate directories before the platform will work.

What This Actually Enables

The result is that Files.com fits your organization's actual identity topology instead of forcing you to simplify your topology to fit the platform. Employees authenticate through the corporate IdP. Contractors authenticate through the vendor's IdP.

Trading partners federate through their own SAML. External collaborators use managed passwords. All of it on a single Files.com site, with a single audit trail, under one set of user and group administration controls.

That is not an exotic feature. It is how enterprise infrastructure is supposed to work.

Enterprise File Management on a Single Platform

Most teams that hit the multiple-IdP wall are running file transfer on a stack of tools that each assume one directory — an SFTP server here, a file-sharing app there, scripts holding the seams together. Files.com is the cloud-native File Orchestration Platform: one platform that replaces that stack. It speaks every protocol — SFTP, FTP, FTPS, HTTPS, and an S3-compatible API — connects 50+ cloud and on-prem systems, automates transfers, and keeps a complete audit trail.

Identity is part of that consolidation, not a bolt-on. Because every user signs in through the right IdP and every action lands in one audit log, an auditor sees a single governed system no matter how many directories feed it. The same site can front storage you already own and reach on-prem systems over a lightweight agent, so you bring your existing identity topology and your existing storage without rebuilding either.

See how Files.com handles multiple SSO providers and user administration, or start a free trial — no credit card, live in minutes.

– Lee Atchison is Field CTO at Files.com and the author of Architecting for Scale (O'Reilly Media). He writes on cloud architecture, enterprise infrastructure, security, and software scalability.