Setting up Authentication by Folder

Before discussing how to define directory authentication, let us review the following points:

• Token-Based Authentication must be configured on each desired platform (i.e., HTTP Large, HTTP Small, and ADN).

  • A primary and/or backup encryption key must be specified for each desired platform.
• Defining an encryption key by itself will not affect content delivery.

The set of content that requires authentication needs to be identified. One way of accomplishing this is to specify the location(s) for which Token-Based Authentication will be applied. The Directories to Authenticate section allows you to define one or more locations using a relative path to the desired folder. The starting point for this relative path, which varies by URL type, is defined below:

URL Type	Relative Path (Starting Point)
CDN URL	Specify a relative path that starts directly after the account number segment of the content access pointThis URL segment of a CDN URL identifies where the request should be directed. This relative path starts directly after the CDN hostname. The proper syntax for a content access point is "/yyAN," where "yy" stands for the origin identifier and "AN" stands for a customer account number. A content access point for a customer origin also includes a directory that identifies it. (e.g., /000001, /200001, or /800001). Sample URL: http://wpc.0001.omegacdn.net/800001/customerorigin/videos/fly.html Gray font indicates the URL segments that should be excluded when securing a location. Any of the configurations listed below will secure the above sample request: / /customerorigin /customerorigin/videos
Edge CNAME URL (CDN Origin)	Specify a relative path that starts directly after the hostname. Sample URL: http://www.domain.com/presentations/sales/businessplan.ppt Gray font indicates the URL segments that should be excluded when securing a location. Any of the configurations listed below will require authentication for the above sample request: / /presentations /presentations/sales
Edge CNAME URL (Customer Origin)	Specify a relative path that starts with the name of the customer origin configuration referenced by the edge CNAME URL. The starting point for the relative path that should be secured is defined in the CDN URL equivalent of an edge CNAME URL. Sample edge CNAME URL: http://www.domain.com/Photos/Store.jpg Our edge servers will re-write the edge CNAME URL requested by the client (above) with the following CDN URL: http://wpc.0001.omegacdn.net/800001/customerorigin/Photos/Store.jpg Gray font indicates the URL segments that should be excluded when securing a location. Any of the configurations listed below will require authentication for the above sample request: / /customerorigin /customerorigin/Photos

Key information:

• The path to a directory always starts with a forward slash (/).
• It may take up to an hour before a new directory configuration takes effect.
• Wildcard characters (e.g., *) are not supported when setting up directories.

Origin Server

Require authentication for all CDN content by defining the following relative path under the Directories to Authenticate section:

Require authentication for all content from a specific customer origin server through the following configuration:

Require authentication for all content from a specific folder on a specific customer origin server through the following configuration:

Although an edge CNAME URL does not include the name of a customer origin server and may not include the path to the desired folder, it will be treated as if the corresponding CDN URL had been used. As a result, when defining such a location make sure to specify the name of the customer origin server followed by the relative path to the desired folder (e.g., /MyCustomerOrigin/Marketing/Presentations).

There is an exception that only applies to the HTTP Large, HTTP Small, and the ADN platforms. A customer origin configuration name does not have to be specified when it contains a period (e.g., www.domain.com). However, for the purpose of clarity and consistency, it is still recommended to do so.

Scope

Token-Based Authentication is applied recursively to each folder specified in the Directories to Authenticate section. This means that all content residing in the specified folder or its subfolders will require authentication.

Token-Based Authentication is platform-specific which means that content may potentially be downloaded by using a URL for a different platform (e.g., HTTP Large instead of HTTP Small). Avoid this scenario by replicating your Token-Based Authentication configuration across all platforms.

Due to the recursive nature of directory authentication, apply Token-Based Authentication to all content for a specific platform by adding the root folder (/).

To apply Token-Based Authentication across an entire platform

1. Navigate to the Token Auth page corresponding to the desired platform.
2. Set the New option, which can be found in the Directories to Authenticate section, to forward slash (/).
3. Click Add.

Administering Authentication Directories

The directories to which Token-Based Authentication will be applied can be administered on a per platform basis. Add, modify, or delete each directory from the Token Auth page corresponding to the desired platform.

It may take up to an hour for the creation, modification, or deletion of an authentication directory to take effect.

To add an authentication directory

1. Navigate to the Token Auth page corresponding to the desired platform.
2. In the New option, which can be found in the Directories to Authenticate section, type the relative path to the desired folder.
3. Click Add.

To modify an authentication directory

1. Navigate to the Token Auth page corresponding to the desired platform.
2. From the Directories to Authenticate section, click next to the desired directory. An edit box indicates that the relative path may now be modified.
3. Modify the relative path to point to the desired directory.
4. Click .

To delete an authentication directory

1. Navigate to the Token Auth page corresponding to the desired platform.
2. From the Directories to Authenticate section, click next to the desired directory.
3. When prompted, click OK to confirm the deletion of that directory.

Sample Scenarios

Although this section contains sample URLs that point to the HTTP Large platform, the analysis provided below also applies to the HTTP Small and the ADN platforms.

The following sample scenarios assume that the following directory has been defined under the Directories to Authenticate section:

Scenario #1

This scenario is based on the following request:

Request Properties	Value
URL Type	CDN URL
Origin Type	CDN Storage
URL	http://wpc.0001.omegacdn.net/000001/Secure/index.html

The above request points to content stored in a folder to which Token-Based Authentication has been applied. Therefore, a token is required. Since a token was not specified for this request, the asset will not be served to the client.

Scenario #2

This scenario is based on the following request:

Request Properties	Value
URL Type	CDN URL
Origin Type	CDN Storage
URL	http://wpc.0001.omegacdn.net/000001/Secure/Data/index.html?c1019f8a6942b46a1ce679e66cd579767

The above request points to content stored in a subfolder of a folder to which Token-Based Authentication has been applied. Therefore, a token is required. The requested asset will be delivered to the client provided that both of the following conditions are met:

• The specified token is valid.
• The requester meets all of the requirements defined in the provided token.

Scenario #3

This scenario is based on the following request:

Request Properties	Value
URL Type	CDN URL
Origin Type	Customer Origin
URL	http://wpc. 0001.omegacdn.net/800001/MyServer/Secure/index.html

The above request points to a customer origin configuration called "MyServer." The requested asset is unprotected, since its relative path starts with "/MyServer" instead of with "/Secure." As a result, it will be served to the client.

Scenario #4

This scenario is based on the following request:

Request Properties	Value
URL Type	Edge CNAME URL
Origin Type	Customer Origin
URL	http://secure.server.com/Secure/index.html?c1019f8a6942b46a1ce679e66cd579767 The hostname "secure.server.com" leverages an edge CNAME configuration that points to: wpc.0001.omegacdn.net/800001/MyServer

The above request leverages an edge CNAME that points to a customer origin configuration called "MyServer" and a folder called "Secure." Although the edge CNAME URL points to the "Secure" folder, the relative path for this type of URL (i.e., edge CNAME URL that points to a customer origin server) starts with the customer origin name (i.e., /MyServer). As a result, the unprotected asset will be served to the client.

Additional Sample Scenarios

We have just examined how several URLs would be affected when the "/Secure" location was defined on an HTTP-based platform. We will now examine how alternate configurations will affect how Token-Based Authentication interacts with those URLs.

Each row in the following table represents a separate Token-Based Authentication configuration.

Secured Location	Description
/	A valid token is required for all four scenarios.
/Secure/Data	A valid token is only required for the second scenario.
/MyServer	A valid token is required for the third and fourth scenarios.
/MyServer/Secure	A valid token is required for the third and fourth scenarios.