SSO With Child Sites

Single sign-on (SSO) providers are configured in a site and each provider applies only to users defined in that site. For many organizations, this means configuring SSO on the parent site and delegating child site access to those users through folder permissions. In this model, users log in at the parent site, and no SSO configuration is needed on the child site.

The purpose(s) of your child sites typically determines when it makes sense to configure SSO on a child site.

When to Configure SSO on a Child Site

For many situations, the default advice to add your identity provider only to the parent site and then assign child site access to those parent site users is straightforward and sufficient. This approach has the advantage of simplifying setup and authentication, since all of those processes take place in the parent site.

Configure an SSO provider on a child site in the situations listed below, where users must log in directly to that child site.

When the Child Site Serves a Different Organization

When a child site serves a sub-organization that has its own identity provider, configure that provider on the child site. Your child site's users will authenticate at the child site and never interact with the parent site. A common example is a business unit acquired through an M&A process. Users in that organization log in only at the child site's domain using their own IdP, and their accounts are isolated from the parent site.

When 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. They log in through the child site's domain, and their accounts are isolated from the parent site. 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.

When Users Require Protocol or API Access to the Child Site

Only users defined in a child site can use FTP or SFTP to connect to that child site. Parent site users with delegated access to child site content cannot use FTP/SFTP with the child site.

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

Default to SSO on Parent Sites Only

When you don't have a compelling reason to allow users to log in directly with the child site, create your SSO integrations for human user accounts in the parent site. To give those users access to child site content, a Parent Site Administrator grants them folder permissions scoped to the appropriate paths within the child site.

Creating the SSO provider in the parent site has the advantage of providing the most straightforward setup and auditing.

When the SSO provider is in the parent site, human users authenticate at the parent site, even if they have access only to child site folders. After login, users with access to only one site are placed there automatically. Users with access to multiple sites choose which one to use when they log in. No SSO configuration is needed on the child site because the authentication happens on the parent site.

Downsides of Re-Using the Same Identity Provider On Multiple Sites

Configuring the same SSO integration on both the parent site and a child site 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 to be configured on more than one site. This means that completing the setup requires special workarounds to make the SSO app credentials unique.

More importantly, a user with accounts on both sites through the same IdP has 2 separate Files.com user accounts with separate permissions and activity logs, and cannot switch sessions between the sites they can access. This means extra work to audit access and trace usage across multiple user accounts.