|« PreviousNext »|
|Did this page help you? Yes | No | Tell us about it...|
Many companies that distribute content via the Internet want to restrict access to documents, business data, media streams, or content that is intended for selected users, for example, users who have paid a fee. To securely serve this private content using CloudFront, you can:
Require that your users use special CloudFront signed URLs to access your content, not the standard CloudFront public URLs.
Require that your users access your Amazon S3 content using CloudFront URLs, not Amazon S3 URLs.
You can control end-user access to your private content in two ways:
You can restrict access to objects in CloudFront edge caches: You can configure CloudFront to require that end users access your objects using special signed URLs. You then create the signed URLs (either manually or programmatically) and distribute them to your users.
When you create signed URLs for your objects, you can specify:
One part of a signed URL is hashed and signed using the private key from a public/private key pair. When someone uses a signed URL to access an object, CloudFront compares the signed and unsigned portions of the URL. If they don't match, CloudFront doesn't serve the object.
You can restrict access to objects in your Amazon S3 bucket: You can secure the content in your Amazon S3 bucket so end users can access it using CloudFront URLs but cannot access it using Amazon S3 URLs. This prevents anyone from bypassing CloudFront and using the Amazon S3 URL to access the content to which you're trying to restrict access. To require that users use CloudFront URLs, you:
Here's an overview of how you use private content to secure access to your Amazon S3 content. Later, we go into greater detail for each step.
To set up private content, you must use the CloudFront console or CloudFront API version 2009-09-09 or later.
You secure your content in Amazon S3 to prevent anyone from bypassing CloudFront and using the Amazon S3 URL to access the content to which you're trying to restrict access. This step is optional, but it's a good idea in case someone learns the Amazon S3 URLs for your content.
Create an origin access identity, which is a special CloudFront user.
Associate the origin access identity with your distribution. (For download distributions, you associate the origin access identity with origins, so you can secure all or just some of your Amazon S3 content.)
Change permissions in Amazon S3 so only the origin access identity can access your objects.
For more information, see Using an Origin Access Identity to Restrict Access to Your Amazon S3 Content.
In your CloudFront distribution, specify one or more trusted signers, which are the AWS accounts that you want to have permission to create signed URLs.
For more information, see Specifying the AWS Accounts That Can Create Signed URLs (Trusted Signers).
You develop your application to create signed URLs for the objects or parts of your application for which signed URLs are required.
For more information about signed URLs, see Overview of Signed URLs.
An end user requests an object for which you want to require signed URLs.
Your application verifies that the end user is entitled to access the object: they've signed in, they've paid for access to the content, or they've met some other requirement for access.
Your application creates and returns a signed URL to the user.
The signed URL allows the user to download or stream the content.
This step is automatic; the user usually doesn't have to do anything additional to access the content. For example, if a user is accessing your content in a web browser, CloudFront returns the signed URL to the browser. The browser immediately uses the signed URL to access the object in the CloudFront edge cache without any intervention from the user.
CloudFront confirms that the URL hasn't been tampered with, and performs the standard CloudFront operations: determines whether the object is already in the edge cache, forwards the request to the origin if necessary, and returns the object to the user.
You can use signed URLs for any CloudFront distribution, regardless of whether the origin is an Amazon S3 bucket or an HTTP server. However, for CloudFront to access your objects on an HTTP server, the objects must remain publicly accessible. Because the objects are publicly accessible, anyone who has the URL for an object on your HTTP server can access the object without the protection provided by CloudFront signed URLs. If you use signed URLs and your origin is an HTTP server, do not give the URLs for the objects on your HTTP server to your customers or to others outside your organization.
You can distribute private content using a signed URL that is valid for only a short time—possibly for as little as a few minutes. Signed URLs that are valid for such a short period are good for distributing content on-the-fly to an end user for a limited purpose, such as distributing movie rentals or music downloads to customers on demand. If your signed URLs will be valid for just a short period, you'll probably want to generate them automatically using an application that you develop. When the user starts to download an object or starts to play a media file, CloudFront compares the expiration time in the URL with the current time to determine whether the URL is still valid.
You can also distribute private content using a signed URL that is valid for a longer time, possibly for years. Signed URLs that are valid for a longer period are useful for distributing private content to known end users, such as distributing a business plan to investors or distributing training materials to employees. You can develop an application to generate these longer-term signed URLs for you, or you can use one of the third-party GUI tools listed in Tools for Configuring Private Content.
For sample code that creates the hashed and signed part of signed URLs, see the following topics:
Additional sample code for creating signed URLs is available on the Amazon CloudFront Sample Code & Libraries page.
For information about third-party tools that support private content, including creating signed URLs, see Tools for Configuring Private Content.