Security overview
Microsoft eCDN is an M365-compliant service. This means it follows all the same security standards maintained by any other M365 service.
This document highlights several articles that are specific to security as it applies to video streaming delivery.
Microsoft eCDN is a hybrid solution, which means that Microsoft eCDN is employed in combination with a traditional HTTP server, while still leveraging the existing security infrastructure (tokens, keys, cookies, etc.) that is already in place.
In terms of communication, there are two main communication channels:
Between peers; peers are connected to each other via the WebRTC data channel, which is a secure tunnel that uses the SCTP protocol over DTLS encryption.
Between each viewer and the Microsoft eCDN backend via a secure WebSocket connection that uses TLS encryption.
Both channels use industry-standard network-security protocols so neither the data sent between two viewers, nor the metadata sent between each viewer and the service's backend can be compromised.
In addition to the above, the service has additional security features that can be enabled, based on individual requirements, which are explained below.
Viewer authentication
Normally, any viewer can connect to the Microsoft eCDN backend and participate in the P2P network. This is acceptable in most use cases, but some customers may prefer to limit which viewers can connect to the service.
In these cases, the backend can authenticate viewers directly, in addition to any authentication mechanisms that may already exist on the content-provider side. The authentication mechanisms Microsoft eCDN has in place prevent unauthorized viewers from accessing content and any metadata that exists on the peer-to-peer network.
Domain allow list
The fastest and easiest way to block most unwanted viewers from participating in peering is by explicitly allowlisting specific domains from which viewers may connect to the service's backend. This means that viewers that try to connect to the service from other, non-allowlisted domains are blocked.
Step-by-step guide:
Go to the Third Party Platforms configuration page in the management console.
Add your domains (the ones where the service scripts are loaded) in the "Website Allow List" box, as shown below.
That's it! Any viewer that tries to connect to the service with your tenant ID from a domain not listed will be blocked.
End-User-IP Allow List
Another means by which admins can block unwanted viewers from participating in peering is by only allowing access to the service from a predefined list of public IPs. This is similar to the "domain allowlisting" feature above, but this time we allowlist the viewers' public IPs.
Step-by-step guide:
Go to the Security configuration page in the management console.
Add the desired public IPs or IP ranges in the "End Users IP Allow List" box in one of the supported formats, as shown below.
That's it! Any viewer that tries to connect to the service with your tenant ID with an IP that isn't allowed is blocked.
Supported formats:
Single IP - Enter each IP in a new line or add them one by one, by clicking the "Add IPs" button after each. Example: 1.1.1.1
CIDR - Enter a CIDR, which represents the IP range you would like to allowlist. Example: 1.1.1.1/24
All formats except JSON (Which must be added on its own) can be mixed and matched by separating them with a new line.
Content protection
Most platforms have multiple ways of protecting streams by preventing access to unwanted viewers. Microsoft eCDN recognizes this and therefore doesn't change any existing content-protection mechanisms.
As would occur without Microsoft eCDN, each user has to authenticate themselves against the server, and only if authenticated successfully will the server send the manifest file to the viewer, which in turn starts requesting segments to play the stream.
Following is a list of the most common protection schemes:
Authentication on session start
In this case, every session begins with the server asking the viewer for their credentials. If these credentials are valid, the server sends the manifest file to the viewer, and the video player starts requesting segments and additional manifests from the HTTP server. Microsoft eCDN doesn't insert itself into this validation process, and the viewer must pass through the same authentication gates whether or not Microsoft eCDN is deployed. Only viewers who are authorized to watch a specific stream can participate in P2P sharing for that stream, and they only share while they're actually watching the stream.
Manifest URI tokenization
Microsoft eCDN also adheres to any existing URI tokenization mechanisms that exist on the manifest level.
With Microsoft eCDN, all manifest requests are sent directly to the HTTP server, so validation takes place with the platform backend in the same manner.
URI timed tokenization
In this case, the manifest URL has an additional token, which encodes details about the viewer's user agent (IP address, expiration time, etc.). A malicious user can distribute the manifest URL to unauthorized viewers, but those viewers won't be able to access the stream since the manifest URL is tokenized and the HTTP server rejects any validation attempts - either because of the IP address or other user agent mismatches or because of time expiration. With Microsoft eCDN, all manifest requests are sent directly to the HTTP server so validation can't be compromised.
Encryption
With content encryption, users need to go through the existing authentication in place and access the decryption key. Microsoft eCDN has no access to the decryption key, and doesn't change the way it's distributed and protected. Microsoft eCDN is agnostic to the different content protection schemes and support standards such as AES-128.
For example, given an HLS stream that is protected with AES-128 encryption, unauthorized viewers won't be able to watch the stream because they won't have access to the decryption key.
The key can be sent to the end user in numerous ways - for example, via the manifest, bundled with the page, or even requested dynamically with custom code.
Microsoft eCDN doesn't insert itself into this process, and the key is delivered to the video player using the same mechanism regardless of whether or not Microsoft eCDN is deployed.
DRM
The DRM use-case resembles the encryption use-case - the only difference is that the license and keys are distributed by the DRM mechanism instead of by the broadcaster. Here as well, Microsoft eCDN doesn't interfere with the distribution of the license or keys and thus doesn't compromise them.