Access Control Policy

Access Control Policies

Access control policies can be applied to some or all resources based on the following criteria:

• Geographic IP Restrictions: The CDN restricts access based on the user's country.

• IP Restrictions: A specific IP address or a range of IPs can have restricted access policies.

These two restrictions can be set through whitelist and blacklist policies. Users within the whitelist will be allowed to download resources.

User access that violates blacklist policies will be denied resource access.

By default, the CDN allows all access. Therefore, to restrict access, customers can create rules as follows:

• Create a blacklist policy to block access from certain sources.

• Create a blacklist policy to block all access and a whitelist policy to allow certain sources.

Policies are named and applied to resources based on URLs, matching by prefix, suffix, or regular expressions. Policies can restrict access by country or a specific IP/network range.

Geographic restriction policies use country codes defined in ISO3166. For example, Vietnam is VN, and Singapore is SG. For IP address policies, a group of IP addresses can be specified using the format IP/CIDR or IP/network class.

Information

A list of country codes can be found at: https://www.iso.org/obp/ui/#search.

IP address groups take precedence over geographic restrictions.

If multiple policies exist, the one with the longest prefix match is used. If multiple policies have the same length, the one with the smallest subnet is selected. Any matching IP range policy takes precedence over geographic policies.

If it is not possible to test policies from the current locations, an additional policy under Access Control (e.g., affecting the customer’s IP address) can be added for testing and later removed. Note that it may take up to ten minutes for policy changes to synchronize across CDN servers.

Token Access

With token access, all connections to the CDN server require a valid encrypted token string to access resources.

A token can be generated by clicking “+”. Token information is only displayed when accessing the admin panel via HTTPS, and customers must store the token value for generating links and accessing resources.

Once a token is created, it is used to generate a query string appended to the URL, allowing user access.

To use a token for time-limited URL access, two values are required:

• stime: Start time of validity

• etime: Expiration time

The format is: yyyymmddHHMMSS

Example

20240801010000 UTC time

Access can also be restricted by IP by adding &ip=1.1.1.1.

For example, a URL structure may look like this: http://www.example.com/path/to/resource?clientId=12345&product=A123&other=xyz

Steps to Implement

• Step 1: Remove the protocol and domain name to get:
  /path/to/resource?clientId=12345&product=A123&other=xyz

• Step 2: Add validity period fields:
  /path/to/resource?clientId=12345&product=A123&other=xyz&stime=20081201060100&etime=20081201183000

• Step 3: Compute and append the encrypted string:

  • Use HMAC-SHA1 to generate a hash string from Step 2 and a secret key.

  • Extract the first 20 characters of the hash, prepend 0, and call this the encrypted string.

  • Append the encrypted string to the URL:

  /path/to/resource?clientId=12345&product=A123&other=xyz&stime=20081201060100&etime=20081201183000&encoded=0<first20chars-of-hash>

The final URL will be: http://www.example.com/path/to/resource?clientId=12345&product=A123&other=xyz&stime=20081201060100&etime=20081201183000&encoded=0<first20chars-of-hash>

Users attempting to access resources without a valid token will receive a "Forbidden" message (HTTP 403) from the browser.