SSO With Child Sites

Single sign-on (SSO) providers are configured per site, and each provider applies only to users defined in that site. The default recommendation is to configure SSO on the Parent Site only. A separate SSO provider on a Child Site is justified in specific situations.

Default: Configure SSO on the Parent Site Only

For most organizations, configure SSO on the Parent Site and grant Child Site access through folder permissions or delegated administration. Users authenticate at the Parent Site and reach their Child Site content from there.

This default keeps one SSO integration to set up and maintain, one identity to audit per person, and one place users go to log in. After login, users with access to only one site are placed there automatically. Users with access to more than one site choose which site to enter. No SSO configuration is needed on the Child Site.

When to Configure SSO on a Child Site

Configure SSO directly on a Child Site in the situations below, where users must log in to that Child Site rather than the Parent Site.

The Child Site Serves a Different Organization

When the Child Site serves a sub-organization that has its own identity provider, configure that provider on the Child Site. The Child Site's users authenticate at the Child Site's domain and never interact with the Parent Site. A common example is a business unit acquired through M&A: the unit's users log in at the Child Site's domain using their own IdP, and their accounts are isolated from the Parent Site.

Users Must Interact Only Through the Child Site's Domain

When the goal is for users to interact exclusively through the Child Site's custom domain rather than the Parent Site, create those users in the Child Site and configure SSO there. Even if you use the same IdP vendor as the Parent Site, you must create a separate app registration in your identity provider for the Child Site.

Users Require Protocol or API Access to the Child Site

Only users defined in the Child Site can use FTP, FTPS, or SFTP to connect to that Child Site. Parent-site users with delegated access to Child Site content cannot use FTP, FTPS, or SFTP to connect to the Child Site.

When your users need both SSO and protocol access to the Child Site, create them in the Child Site and configure SSO there. They authenticate through the Child Site's SSO for web and desktop access and use SFTP/SSH keys or API keys for protocol connections.

Costs of Re-Using the Same Identity Provider Across Sites

Configuring the same identity provider on both the Parent Site and a Child Site is supported but adds setup complexity, creates separate user accounts, and makes auditing harder.

Each SSO configuration in Files.com requires separate app credentials from your identity provider, and Files.com does not allow the same app credentials on more than one site. Completing the setup requires unique app credentials per site in the IdP.

A user with accounts on both sites through the same IdP has two separate Files.com user accounts, with separate permissions and separate activity logs, and cannot switch between the sites without logging out and logging back in. Auditing access and tracing usage takes extra work across the duplicate accounts.

When the goal is for one person to reach both the Parent Site and Child Site content, the default pattern (SSO on the Parent Site, delegated access to the Child Site) is the cleaner setup.