Accessing Child Sites

A user can have access to a Child Site through four distinct paths, and the right path depends on how the user works and which interfaces they use. See Child Sites for an overview of what Child Sites are, and Parent and Child Site Administrators for the administrator roles.

How Users Access a Child Site

A user can reach a Child Site through any of the following:

• They are a Parent Site Administrator, with full access to every Child Site.
• Their account on the Parent Site has folder permissions scoped to paths inside a Child Site.
• Their account on the Parent Site has been granted administrative access (Site Administrator or Read-only Administrator) on a Child Site.
• Their account exists directly inside the Child Site.

The first three paths are forms of delegated access from the Parent Site. The user is provisioned once on the Parent Site and reaches Child Site content from there. The fourth path is a Child Site native account, which exists only in the Child Site and cannot reach the Parent Site or any sibling Child Site.

Access is one-way: Child Site users, including Child Site Administrators, cannot be granted permissions on the Parent Site or any other Child Site. This restriction keeps the security model simple, with access flowing from parent to child only.

Logging In

Users with delegated access from the Parent Site log in at the Parent Site. After login, users who have access to only one site are placed there automatically. Users who have access to more than one site choose which site to enter.

Users with a native account on the Child Site log in at the Child Site's custom domain or subdomain.

Across Interfaces

Web Interface. Parent Site Administrators switch between sites through a menu next to the logo. Parent-site users with delegated access choose their site at login or switch between sites afterward. Child Site native users log in directly to the Child Site's domain.

Desktop and Mobile Apps. Parent-site users with delegated access can connect to a Child Site through the Desktop App and Mobile App. Child Site native users connect to their Child Site directly.

FTP and SFTP. Protocol authentication cannot cross sites. Only users with a native account on the Child Site can connect to it via FTP, FTPS, or SFTP. Parent-site users with delegated access to a Child Site cannot use FTP or SFTP against that Child Site.

API. API keys are linked to one site. A key issued on the Parent Site only works against the Parent Site; a key issued on a Child Site only works against that Child Site. See Using API Keys with Child Sites.

CLI. The Files.com CLI supports multiple profiles, which is the right pattern for operators who work across a Parent Site and one or more Child Sites. Each profile authenticates against one site.

When to Create Users Directly in a Child Site

Most users who need access to a Child Site can be granted that access from the Parent Site. Delegating from the Parent Site means one account to manage, one identity to audit, and one place to revoke access. Create users directly in the Child Site in the situations below.

Protocol or API Access to the Child Site

A user who needs to connect to the Child Site via FTP, SFTP, or API keys must have a native account on the Child Site. Protocol authentication cannot cross sites, and API keys are linked to a single site. Machine accounts and service accounts commonly fall in this category. They connect with API keys or SFTP/SSH keys and cannot switch sessions the way a human user can.

Administration Delegated to a Child Site Administrator

When a Child Site Administrator is responsible for managing the Child Site's users, those users are created in the Child Site. The Child Site Administrator has authority only inside the Child Site and cannot create or manage accounts on the Parent Site.

Distinct Brand, Subsidiary, or Acquisition

When the Child Site supports a separate brand, subsidiary, or acquired company, and users will never interact with the Parent Site, create those users directly in the Child Site. Pair this with a custom domain and, typically, a separate SSO provider so users authenticate against the subsidiary's identity infrastructure and never see the Parent Site.

Permissions Audit Export

The permissions audit export shows the permissions granted to users. When run from the Parent Site, the export includes permissions for the Parent Site and every Child Site. When run from a Child Site, the export includes permissions for that Child Site only.