Streaming domains implement various access control policies, including URL signing, Referer-based hotlink protection, IP address blacklist and whitelist, protocol prohibition, region blocking, and remote authentication, to effectively prevent unauthorized access and illegal use, and enhance the security and user experience of live streaming services. Users can select and configure appropriate access control policies based on their business and security requirements to ensure the security and stable operation of live streaming resources.
Overview
Access control for streaming domains is an important means to ensure resource security and prevent unauthorized use, mainly including the following methods:
URL signing: URL signing can effectively prevent issues that Referer-based hotlink protection cannot fully protect against, ensuring the legitimacy of each request.
Referer-based hotlink protection: By configuring custom blacklists/whitelists and rule content through Referer-based hotlink protection, you can allow or reject playback requests to protect live streaming content.
IP address blacklist and whitelist: IP address blacklists and whitelists can restrict or allow access from specific IP addresses, enabling identification and filtering of visitor identities.
Protocol prohibition: By restricting the playback protocols of the current domain, once enabled, the corresponding playback protocols under that domain will be unavailable, and playback address requests generated by the prohibited protocol will be rejected.
Region blocking: Through playback region management configuration, you can specify blacklists or whitelists for playback regions to manage the playback regions of the current domain.
Remote authentication: Remote authentication can forward user requests to a specified authentication server for verification, further enhancing the flexibility and security of access control.
URL signing
How it works
ApsaraVideo Live works with your live streaming server to implement URL signing to protect live streaming resources against hotlinking in a more secure and reliable manner.
A live streaming server of a user provides a signed URL that contains authentication information.
Stream ingest or streaming users send a request to ApsaraVideo Live by using the signed URL.
ApsaraVideo Live verifies the authentication information in the signed URL to determine whether the request is valid. ApsaraVideo Live processes valid requests and rejects invalid requests.
After your request URL is authenticated by ApsaraVideo Live, special characters in the URL, such as =
and +
, are escaped.
For more information about the scenarios, composition, and principles of URL signing, see Authentication of ingest and streaming URLs.
Configure URL signing
- Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
Click .
Click the URL Signing tab and click Change Settings.
NoteWhen you add a domain name for the first time, URL Signing is enabled by default. You can Modify the configuration only when URL signing is enabled.
Configure URL signing and click OK.
The following table describes the parameters.
Parameter
Description
Authentication Type
ApsaraVideo Live streaming domains support only Authentication Type A to protect resources on the origin server.
NoteIf URL signing fails, HTTP status code 403 is returned. In this case, you must recalculate the signature.
Invalid MD5 values
Example:
X-Tengine-Error:denied by req auth: invalid md5hash=de7bfdc915ced05e17380a149bd760be
Invalid timestamps
Example:
X-Tengine-Error:denied by req auth: expired timestamp=1439469547
Primary Key
After you add a domain name, ApsaraVideo Live generates a random primary key for the domain name. You can view the primary key on the URL Signing page. To go to the URL Signing page, choose Domain Names in the left-side navigation pane, find the domain name that you want to configure, and click
. You can also change the primary key for the selected authentication type.Secondary Key
Specify the secondary key for the selected authentication method.
NoteThe primary key and secondary key have the same effect. The secondary key is mainly used for smooth replacement.
If the primary key is replaced, the signed URL generated by using the primary key becomes invalid. If you write the old primary key to the secondary key during replacement, the secondary key can continue to provide services instead of the primary key.
Validity Period
The validity period indicates the period of time during which URL signing is valid for stream ingest or playback. Live stream ingest and playback are long-connection behaviors. Established connections are not terminated when the validity period expires, but new requests fail due to expiration. The default validity period for a new domain name is one day (1,440 minutes). You can customize the validity period. The minimum validity period is 1 minute, and there is no upper limit.
Disable URL signing
Before you disable URL Signing, understand the risks of unauthorized access and sign the Disclaimer Agreement for Disabling URL Signing.
After you disable URL Signing, you can generate permanently valid stream ingest or streaming URLs.
On the URL Signing tab, click Sign Agreement.
In the Sign Agreement dialog box, select the check box and click Sign Agreement.
After the Disclaimer Agreement for Disabling URL Signing is signed, click OK.
Turn off the URL Signing switch. After URL signing is disabled, you cannot encrypt URLs by setting cryptographic keys.
Referer-based hotlink protection
How it works
The hotlink protection feature identifies the source of requests based on the Referer mechanism of the HTTP protocol and supports blacklist or whitelist mechanisms. ApsaraVideo Live nodes filter visitor identities based on preset lists. Users who meet the rules can access resources, while users who do not meet the rules receive a 403 response.
Hotlink protection is optional, and is disabled by default.
The blacklist and whitelist are mutually exclusive. You can enable only one of them at the same time.
When you configure a Referer blacklist or whitelist, wildcard domain names can be automatically added. For example, if you enter
example.com
, the configuration that takes effect is*.example.com
. All child domain names take effect.You can specify whether to allow requests with an empty Referer header to access your resources. If you allow such requests, users can directly access the resources by entering the URL into the address bar of a browser.
In most cases, mobile clients cannot obtain the Referer header. By default, requests with an empty Referer header are allowed. If you do not allow requests with an empty Referer header, you can use ApsaraVideo Player SDK to configure the Referer header for requests on mobile clients.
When you do not allow requests with an empty Referer header, you must configure HTTPS Secure Acceleration and enable force redirect to HTTPS (HTTP > HTTPS). Some browsers remove the Referer header when processing HTTP resources in HTTPS requests, which causes access failures.
Procedure
- Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
Click .
Click the Referer-based Hotlink Protection tab and turn on Referer-based Hotlink Protection.
Configure Type and Referrers, and click OK.
The following table describes the types of Referer-based hotlink protection.
Type
Description
Blacklist
Requests from domain names that are included in the blacklist cannot access your resources.
Whitelist
Only requests from domain names that are included in the whitelist can access your resources.
IP address blacklist and whitelist
How it works
If you configure an IP address blacklist, IP addresses in the blacklist are not allowed to access the accelerated domain name.
If you configure an IP address whitelist, only IP addresses in the whitelist can access the accelerated domain name.
IP address blacklist and whitelist support IPv6 addresses. Letters in IPv6 addresses must be uppercase. Examples: 2001:DB8:0:23:8:800:200C:417A and 2001:0DB8:0000:0023:0008:0800:200C:417A. You cannot shorten an IPv6 address by using the two-colon (::) notation. For example, 2001:0DB8::0008:0800:200C:417A is invalid.
IP address blacklist and whitelist support CIDR blocks. For example, in the 192.168.0.0/24 CIDR block, /24 indicates that the first 24 bits in the subnet mask are network bits. The remaining 8 bits are host bits. The number of host bits is calculated based on the following formula: 32 - 24 = 8. The subnet can accommodate up to 254 hosts. The number of hosts is calculated based on the following formula: 2^8 - 2 = 254. Therefore, 192.168.0.0/24 indicates IP addresses from 192.168.0.1 to 192.168.0.254.
Procedure
- Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
Click the IP Blacklist or Whitelist tab and turn on IP Blacklist or Whitelist.
Configure List Type and Rule, and click OK.
Type
Description
Blacklist
Requests from domain names that are included in the blacklist cannot access your resources.
Whitelist
Only requests from the domain names that are included in the whitelist can access your resources.
Choose .
Protocol prohibition
How it works
The protocol prohibition feature prohibits streams of specified protocols under a specific streaming domain. The streaming domain can be a main streaming domain or sub-streaming domain. After you prohibit a protocol for a streaming domain, you cannot use the corresponding streaming URL over the protocol for playback.
In addition to the console, you can also call the BatchSetLiveDomainConfigs operation and pass the alilive
record in the Functions parameter. For more information, see BatchSetLiveDomainConfigs.
Procedure
Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
Click the Protocol Prohibition tab, select the protocol that you want to prohibit, and turn on the prohibition feature.
Choose .
Region blocking
How it works
The region blocking feature identifies the source regions of client access requests, blocks access from specific regions, or allows access only from specific regions, solving issues such as malicious requests from certain regions and content distribution copyright.
The HTTP Live Streaming (HLS), Real-Time Messaging Protocol (RTMP), Flash Video (FLV), and Real-Time Streaming (RTS) protocols for streaming are supported.
You can configure region blocking at the domain name level or at the stream level. If you add a region to a domain-level whitelist and a stream-level blacklist, the region is blocked at the stream level. If you add a region to a domain-level blacklist and a stream-level whitelist, the region is blocked at the domain name level.
You can configure both Domain-level Region Blocking and Stream-level Region Blocking at the same time. If there is a conflict between the blacklist and whitelist of the two, the configured blacklist takes precedence for blocking access to regions.
Configure domain-level region blocking
Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
On the Region Blocking tab, turn on the Domain-level Region Blocking switch, and select Blocking Type and Blocked Regions.
Parameter
Description
Blocking Type
Blacklist: All requests from the regions in the blacklist are blocked from accessing resources in the streaming domain.
Whitelist: Only requests from the regions in the whitelist are allowed to access resources in the streaming domain.
The blacklist and whitelist are mutually exclusive. Only one of them can take effect at a time.
Blocked Regions
Add regions to the blacklist or whitelist.
Click OK to complete the configuration.
Choose .
Configure stream-level region blocking
Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
Click the Region Blocking tab and click Add under Stream-level Region Blocking.
Parameter
Description
AppName
The name of the application to which the live stream belongs.
NoteThe name can be up to 256 characters in length and can contain digits, letters, hyphens (-), underscores (_), and equal signs (=). The blocking rule takes effect only if the value of this parameter is the same as the application name specified in the streaming URL.
StreamName
The name of the live stream.
NoteThe name can be up to 256 characters in length and can contain digits, letters, hyphens (-), underscores (_), and equal signs (=). The blocking rule takes effect only if the value of this parameter is the same as the stream name specified in the streaming URL.
Blocking Type
Blacklist: All requests from the regions in the blacklist are blocked from accessing resources in the streaming domain.
Whitelist: Only requests from the regions in the whitelist are allowed to access resources in the streaming domain.
NoteThe blacklist and whitelist are mutually exclusive. Only one of them can take effect at a time.
Blocked Regions or Allowed Regions
The regions in the blacklist or whitelist.
Expiration Time
The time when the blocking rule expires. By default, the expiration time of the rule is seven days from now. Modify this parameter based on your business requirements.
Click OK to complete the configuration.
View the stream-level region blocking rule. After you add a stream-level region blocking rule, you can refresh the rule list to view the rule status. You can query rules based on AppName, StreamName, and the type of the rule (blacklist or whitelist).
Choose .
Remote authentication
How it works
Both remote authentication and URL signing protect live streaming resources, ensuring that only successfully authenticated users can access these resources. The two methods have the following technical implementation differences:
URL signing: Users distribute the authentication rules of the domain name to the live center, and the live center completes the entire data interaction process of authentication.
Remote authentication: Users have their own separately configured authentication server. After the live center receives a user request, it needs to forward the user request to the authentication server to complete the authentication. The authentication server is established and managed by the user. Remote authentication does not support the HLS protocol.
The data interaction process of the remote authentication feature is as follows:
Number | Interaction description |
1 | The user initiates a resource access request to the live center, with authentication parameters included in the request. |
2 | The live center receives the user request and forwards it directly (or after processing according to specified rules) to the authentication server. |
3 | The authentication server provides an authentication result based on the authentication parameters in the user request and returns it to the live center. |
4 | The live center performs the corresponding action based on the authentication result returned by the authentication server and returns the corresponding data to the user.
|
Procedure
- Log on to the ApsaraVideo Live console.
In the left-side navigation pane, click Domain Names. The Domain Management page appears.
Find the streaming domain that you want to configure and click Domain Settings in the Actions column.
Click the Remote Authentication tab, turn on the Remote Authentication switch, and configure the remote authentication parameters according to the interface prompts.
NoteAfter you enable remote authentication, all user requests are redirected to the authentication server. If many requests are sent to POPs, ensure that the authentication server can handle traffic spikes without compromising performance.
Parameter
Description
Authentication Server Address
The address of the authentication server. This address must be publicly accessible. The system checks whether the format and value of the address that you enter are valid. You can specify a fixed URL or a variable concatenated URL.
Fixed URL: The HTTP and HTTPS protocols are supported. The value cannot contain 127.0.0.1 and localhost, which are invalid local addresses. Sample formats:
http(s)://example.aliyundoc.com/auth
http(s)://192.0.2.1/auth
Variable concatenated URL: You can construct a signed URL by concatenating variables and then use the URL as the address of the authentication server. For more information about the rules for variable concatenated URLs, see Variable concatenated URL.
Pass-through Request URL Parameters
Specify the URL parameters that you want the authentication server to check. You can select Pass Through Specified Parameters, Do Not Pass Through Specified Parameters, or Do Not Pass Through Request URL Parameters.
NoteIf you select Pass Through Specified Parameters or Do Not Pass Through Specified Parameters, enter the specified parameters that you want to pass through in the input box below. Separate multiple parameters with commas (,). Example:
key1,key2,key3
.HTTP Status Code For Authentication Result
The HTTP status code that the authentication server returns to the live center. You can select one of the following options:
HTTP Status Code For Successful Authentication: After you select this option, enter a custom HTTP status code for successful authentication in the input box below. The live center allows user requests only when the authentication server returns this HTTP status code. The live center blocks user requests when the authentication server returns other HTTP status codes.
If you set the HTTP status code to 200, the authentication server returns the HTTP 200 status code to POPs for client requests that pass the authentication.
HTTP Status Code For Failed Authentication: After you select this option, enter a custom HTTP status code for failed authentication in the input box below. The live center blocks user requests only when the authentication server returns this HTTP status code. The live center allows user requests when the authentication server returns other HTTP status codes.
If you set the HTTP status code to 403, the authentication server returns the HTTP 403 status code to POPs for client requests that fail the authentication.
Authentication Duration (Seconds)
The period of time that starts when the live center initiates authentication and ends when the live center receives the authentication result from the authentication server.
Valid values: integers from 0 to 30.
Number Of Authentication Timeout Retries
The number of times that the authentication server retries authentication if the specified authentication duration is exceeded. After the number of retries reaches the specified value, the action that you specify for authentication timeout is performed. You can select Allow or Reject.
Action After Authentication Timeout
The action that you want to perform on requests when the data interaction between the live center and authentication server times out. You can select Allow or Reject. The differences are as follows:
Allow: If authentication times out, the live center directly allows user requests.
Reject: If authentication times out, the live center rejects user requests and returns the HTTP status code for failed authentication (such as HTTP status code 403) to users.
Asynchronous Authentication (Advanced Configuration)
If you enable asynchronous authentication, a stream can be played without the need to wait for the authentication result. If the result that is returned at a later point in time indicates failed authentication, the playback is interrupted. This helps prevent the issue of increased first frame duration that is caused by the synchronization of the authentication result.
Click OK to complete the parameter configuration.
After you successfully configure remote authentication, you can modify the current configuration or disable remote authentication on the Remote Authentication tab.
Choose .
Variable concatenated URL
You can construct a signed URL by concatenating variables and then use the URL as the address of the authentication server. The following table describes the variables.
Type | Description |
Numeric variables | Numeric variables such as For example, if the stream ingest URL is |
Alphabetic variables | Alphabetic variables such as For example, if the stream ingest URL is |
Custom variables | Custom variables start with the |
ngx variables | All All values referenced through variables are processed by the URL escape function |
Stream name variables | You can add variables in the format of |
If the stream ingest or streaming URL is rtmp://domain.aliyundoc.com/app/stream?token=***&name=xrc
.
The address of the authentication server is configured as http://auth.aliyundoc.com/?app=${udv_host}&streamname=${2}&appname=${1}&token=${arg_token}
.
The actual authentication address is http://auth.aliyundoc.com/?app=domain.aliyundoc.com&streamname=stream&appname=app&token=***
.