Skip to main content

STS Role Assumption Security

AWS Security Token Service (STS) lets Files.com access your S3 bucket with temporary credentials issued for an IAM role in your AWS account. The role defines the access; its trust policy defines who may assume it. This avoids storing a long-lived IAM user's access key for the connection.

Principal and External ID

During setup, Files.com displays a sample trust policy containing the Files.com Principal ARN and your site's External ID. Apply both to the role's trust relationship.

The Principal ARN identifies the Files.com AWS identity allowed to request credentials. It is shared across Files.com sites because it identifies the calling service. The External ID identifies your site's relationship with that role and is derived from the site's fully qualified domain name, such as acme.files.com.

The External ID is not a password and is not intended to be secret. Knowing it does not grant access: AWS also requires an authenticated request from the trusted Files.com principal. Conversely, a request from that principal must include the matching External ID. Together, the two requirements let your role distinguish the intended Files.com relationship from another request.

Use the exact values displayed for your connection. AWS's external-ID guidanceExternal LinkThis link leads to an external website and will open in a new tab explains this third-party trust arrangement.

Credential Lifetime and Permissions

Files.com requests temporary credentials for the role and renews them automatically. Assume Role Session Duration defaults to 3600 seconds, or one hour, and must not exceed the role's Maximum session duration in AWS. Each set of credentials stops working when it expires.

The trust relationship does not itself grant S3 access. Attach the bucket permissions required for the integration, scoped to its bucket and paths. Access to objects encrypted with AWS KMS also requires the corresponding KMS permissions.

Compared with a long-lived IAM user key, STS limits each credential's lifetime and keeps the role's access policy under your AWS account's control. Your team remains responsible for maintaining the trust policy and the permissions needed by dependent Mounts, Syncs, and other workflows.