Here's a premise that most enterprise software vendors quietly ignore: your organization's users are not a single, coherent population. Neither is your identity infrastructure.

You have employees. Contractors. Subsidiaries. Trading partners. They each bring their own Active Directory, their own Okta tenant, their own SAML configuration.

Most platforms that support SSO handle this quite simply. They simply require you to pick one.

Pick one identity provider.

Pick one canonical user directory.

Pick just one.

Everyone accessing their platform has to authenticate through that one system. If they aren’t in that one system? Then they get their own standalone, application-managed password.

Welcome to life outside the corporate identity management system. Assuming of course your security team allows it.

Why One SSO Is Often the Wrong Answer

The pressure to standardize on a single identity provider (IdP) is real. And, frankly, this is a good goal for good reasons. Fewer IdP integrations means fewer attack surfaces, simpler access audits, and a cleaner deprovisioning story.

In an ideal world, all users flow through one authoritative directory.

But the enterprise world doesn't always look that simple. Consider these not-so-uncommon cases:

Employees and contractors. Many organizations maintain identity systems for full-time employees that’s separate from the contractor’s identity system. This separation is done for good reasons that span legal, HR, and security. Your employees live in Entra ID. Your contractors are managed by the staffing agency's Okta. You need both populations to have SSO access to the file transfer platform, governed by their own respective IdPs, with no credential commingling.

Mergers and acquisitions. During an M&A integration, two organizations rarely have identical identity infrastructure. The acquired company has its own IdP; the parent company has its own. Forcing an immediate IdP migration mid-acquisition is a high-risk project that can take months of planning and execution. You want both directories to work concurrently during the transition, so that you can have a clean cutover path when you're ready.

Partner and vendor access. A trading partner connecting via AS2 or SFTP may want their own identity federation rather than maintaining Files.com-managed passwords for every user on their side. That's a reasonable ask and supporting it increases trust. But their IdP is theirs, not yours.

Subsidiaries and business units. Larger organizations sometimes operate subsidiaries or brands with distinct IT environments. Each may have its own directory. The parent company wants unified file infrastructure without forcing an identity consolidation that the subsidiary isn't ready for.

In each of these cases, you need more than one identity provider in play at the same time. The question is whether your file management platform supports that cleanly.

Files.com was built with this topology in mind.

How Files.com Handles The Multiple SSO Mess

Files.com supports multiple SSO providers on a single site. Okta, Microsoft Entra ID, OneLogin, JumpCloud, Google, Duo, LDAP. You can add as many identity providers as your deployment requires. Each user is assigned to exactly one provider, and the login page presents the appropriate sign-in option for each.

For organizations running multiple tenants of the same IdP, such as two separate Okta environments from an M&A scenario, Files.com handles this via SAML. You can configure multiple SAML instances of the same provider and distinguish them by display name on the login page. Each instance authenticates against its own IdP configuration independently.

The provisioning layer is equally flexible. Files.com supports SCIM provisioning against multiple providers simultaneously. When a user is added to your Entra ID tenant, they can be automatically provisioned into Files.com. When a contractor is added to a separate Okta environment, same thing. Just-in-Time provisioning is available for environments where you want accounts created automatically on first login without the overhead of full SCIM synchronization.

You can also mix authentication methods. Some users can authenticate through one SSO, some through another, and others through Files.com-managed passwords. This is particularly useful for external collaborators or legacy service accounts that don't exist in any of your IdPs.

There is one important caveat you must consider. Each user account is tied to a single authentication method. If you need the same person to have access under two different IdPs, you end up creating two user accounts. This might be the case during an M&A transition, for example. Two user accounts for one person does create a tradeoff and a minor transition inconvenience. But in most cases, it’s more than offset by the overall improvement in migration flexibility.

What This Actually Enables

The practical outcome of all of this is that Files.com can fit into an organization's actual identity topology, rather than forcing the organization to simplify its topology to fit the platform.

Your employees authenticate through the corporate IdP. Your contractors authenticate through the vendor IdP. Your trading partners federate via their own SAML configuration. Your external collaborators use managed passwords.

All of this happens on a single Files.com instance, with a single audit trail, under a single governance model.

That's not a complicated feature. It's just how enterprise infrastructure should work.

– 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.