STS Role Assumption Security

Amazon STS (Security Token Service) is an AWS service that issues temporary, limited-privilege credentials for accessing AWS resources.

When you configure an S3 Remote Server to use STS, the Files.com setup process displays two pieces of information: an External ID and a sample trust policy containing the Files.com Principal ARN. The External ID is generated from your site's fully qualified domain name (FQDN). The trust policy is used in your IAM role configuration in AWS. These two values are the foundation of the security model.

The trust policy enforces two conditions that must both be true for AWS to issue credentials:

1. The request must come from the specific IAM principal identified in the policy (the Files.com AWS account).
2. The request must include an External ID that matches the value in the policy.

Neither condition alone is sufficient.

An entity that knows the External ID, but cannot authenticate as the Files.com IAM principal, cannot assume your role. An entity within the Files.com AWS account that does not supply the correct External ID also cannot assume your role.

This two-condition design prevents a class of vulnerability known as the "confused deputy problem", where a service is tricked into using its own privileges on behalf of an unauthorized party.

About the External ID

The External ID displayed during setup is derived from your site's fully qualified domain name (FQDN), for example, acme.files.com. Because the FQDN is not secret, some security teams flag this as a concern. However, the External ID is not intended to be a secret. Its purpose is to uniquely identify the relationship between Files.com and your AWS account. The security comes from the combination: only the Files.com IAM principal can call sts:AssumeRole against your role, and only with your site's specific External ID. An outside party who knows your FQDN cannot use it to assume your role because they cannot authenticate as the Files.com principal.

For more information on how External IDs prevent confused deputy attacks, see AWS's documentation about how to use an external ID when granting access to your AWS resources to a third party.

About the Principal ARN

The Principal ARN shown in the sample trust policy identifies the specific IAM entity in the Files.com AWS account that is permitted to assume your role.

This ARN is the same across all Files.com tenants by design, because it identifies Files.com as the calling service. The per-tenant differentiation comes from the External ID, not the Principal ARN. AWS rejects any AssumeRole request from a different principal, regardless of whether the correct External ID is supplied.

Temporary Credentials vs. Long-Lived Access Keys

When you use IAM access keys (the Access Key plus Secret Key method), those credentials remain valid until you manually rotate or delete them. If they are exposed at any point, they can be used until you discover the exposure and take action.

STS role assumption works differently. Files.com requests temporary credentials from AWS each time it needs access. These credentials expire automatically. The default is 1 hour, but you can configure it using the Assume Role Session Duration setting. They are never stored permanently. If a temporary credential were somehow intercepted, it would stop working when it expires. Files.com requests new credentials automatically before the current ones expire, so your S3 operations are not interrupted.

This is why AWS recommends temporary credentials over long-lived access keys for cross-account access. The exposure window for any single credential is limited to its remaining lifetime, and there are no permanent secrets stored in a third-party system that could be targeted.