使用 Azure 媒体服务设计带访问控制的内容保护系统Design of a content protection system with access control using Azure Media Services

备注

Google Widevine 内容保护服务目前在 Azure 中国区域不可用。Google Widevine content protection services are currently unavailable in the Azure China regions.

概述Overview

针对 Over-The-Top (OTT) 或在线流解决方案设计和构建数字版权管理 (DRM) 子系统是相当复杂的任务。Designing and building a digital rights management (DRM) subsystem for an over-the-top (OTT) or online streaming solution is a complex task. 运营商/在线视频提供商通常会将此任务外包给专门的 DRM 服务提供商。Operators/online video providers typically outsource this task to specialized DRM service providers. 本文档旨在陈述 OTT 或在线流解决方案中端到端 DRM 子系统的参考设计和实现。The goal of this document is to present a reference design and implementation of an end-to-end DRM subsystem in an OTT or online streaming solution.

本文档的目标读者是使用 OTT 或在线流/多屏解决方案的 DRM 子系统的工程师,或对于 DRM 子系统有兴趣的读者。The targeted readers for this document are engineers who work in DRM subsystems of OTT or online streaming/multiscreen solutions or readers who are interested in DRM subsystems. 假设读者熟悉市场上的至少一种 DRM 技术,例如 PlayReady、FairPlay 或 Adobe Access。The assumption is that readers are familiar with at least one of the DRM technologies on the market, such as PlayReady, FairPlay, or Adobe Access.

在 DRM 方面,本文还会介绍使用多重 DRM 的 CENC(通用加密)。In this discussion of DRM, we also include common encryption (CENC) with multi-DRM. 在线流和 OTT 行业中的主要趋势是在各种客户端平台上使用 CENC 与多重原生 DRM。A major trend in online streaming and the OTT industry is to use CENC with multi-native DRM on various client platforms. 这是从以前对于各种客户端平台使用单个 DRM 及其客户端 SDK 的趋势变化而来的。This trend is a shift from the previous one that used a single DRM and its client SDK for various client platforms. 将 CENC 与多重原生 DRM 一起使用时,PlayReady 将按照通用加密 (ISO/IEC 23001-7 CENC) 规范进行加密。When you use CENC with multi-native DRM, PlayReady is encrypted per the Common Encryption (ISO/IEC 23001-7 CENC) specification.

使用 CENC 与多重 DRM 的好处如下:The benefits of CENC with multi-DRM are that it:

  • 降低加密成本,因为对于不同平台使用其原生 DRM 进行单一加密处理。Reduces encryption cost because a single encryption process is used to target different platforms with its native DRMs.
  • 降低管理加密资产的成本,因为只需要一份加密资产。Reduces the cost of managing encrypted assets because only a single copy of encrypted assets is needed.
  • 消除 DRM 客户端许可成本,因为原生 DRM 客户端在其原生平台上通常是免费提供的。Eliminates DRM client licensing cost because the native DRM client is usually free on its native platform.

本文的目标Goals of the article

本文的目标是:The goals of this article are to:

  • 提供使用 CENC 与多重 DRM 的 DRM 子系统的参考设计。Provide a reference design of a DRM subsystem that uses CENC with multi-DRM.
  • 提供 Azure/媒体服务平台上的参考实现。Provide a reference implementation on an Azure/Media Services platform.
  • 讨论一些设计和实现主题。Discuss some design and implementation topics.

在本文中,“多重 DRM”一词涵盖以下产品:In the article, the term "multi-DRM" covers the following products:

  • Microsoft PlayReadyMicrosoft PlayReady
  • Apple FairPlayApple FairPlay

下表汇总了每个 DRM 支持的原生平台/原生应用和浏览器。The following table summarizes the native platform/native app and browsers supported by each DRM.

客户端平台Client platform 原生 DRM 支持Native DRM support 浏览器/应用Browser/app 流格式Streaming formats
智能电视、操作员 STB、OTT STBSmart TVs, operator STBs, OTT STBs 主要为 PlayReady,和/或其他PlayReady primarily, and/or other Linux、Opera、WebKit 及其他Linux, Opera, WebKit, other 各种格式Various formats
Windows 10 设备(Windows 电脑、Windows 平板电脑、Windows Phone、Xbox)Windows 10 devices (Windows PC, Windows tablets, Windows Phone, Xbox) PlayReadyPlayReady Microsoft Edge/IE11/EMEMicrosoft Edge/IE11/EME


通用 Windows 平台Universal Windows Platform
DASH(对于 HLS,不支持 PlayReady)DASH (for HLS, PlayReady isn't supported)

DASH、平滑流式处理(对于 HLS,不支持 PlayReady)DASH, Smooth Streaming (for HLS, PlayReady isn't supported)
iOS(iPhone、iPad)、OS X 客户端和 Apple 电视iOS (iPhone, iPad), OS X clients and Apple TV FairPlayFairPlay Safari 8+/EMESafari 8+/EME HLSHLS

考虑到每种 DRM 的当前部署状态,服务通常需要实现两个 DRM,才能确保以最佳方式处理所有类型的终结点。Considering the current state of deployment for each DRM, a service typically wants to implement two DRMs to make sure you address all the types of endpoints in the best way.

必须在服务逻辑复杂性与客户端复杂性之间做出取舍,以便各种不同客户端上的用户体验能够达到特定的程度。There is a tradeoff between the complexity of the service logic and the complexity on the client side to reach a certain level of user experience on the various clients.

做出选择时,请记住以下几点:To make your selection, keep in mind:

  • PlayReady 原生实现在每种 Windows 设备和部分 Android 设备上,且可通过软件 SDK 在几乎所有平台上实现。PlayReady is natively implemented in every Windows device, on some Android devices, and available through software SDKs on virtually any platform.
  • FairPlay 只可在 iOS 和 Mac OS 客户端中使用,或通过 iTunes 使用。FairPlay is available only on iOS and Mac OS clients or through iTunes.

参考设计A reference design

本部分探讨一种参考设计,这种设计与用于实现它的技术无关。This section presents a reference design that is agnostic to the technologies used to implement it.

DRM 子系统可能包含以下组件:A DRM subsystem can contain the following components:

  • 密钥管理Key management
  • DRM 打包DRM packaging
  • DRM 许可证传送DRM license delivery
  • 权利检查Entitlement check
  • 身份验证/授权Authentication/authorization
  • 播放器Player

下图演示了 DRM 子系统中组件之间的高级交互:The following diagram illustrates the high-level interaction among the components in a DRM subsystem:

使用 CENC 的 DRM 子系统

设计中包含三个基本层:The design has three basic layers:

  • 后端办公系统层(黑色表示),不对外部公开。A back-office layer (black) is not exposed externally.
  • 外围网络层(蓝色表示),包含所有面向公众的终结点。A DMZ layer (dark blue) contains all the endpoints that face the public.
  • 公共 Internet 层(浅蓝色表示),包含具有跨公共 Internet 流量的播放器。A public internet layer (light blue) contains the players with traffic across the public internet.

无论是静态加密还是动态加密,也都应该有一个用于控制 DRM 保护的内容管理工具。There also should be a content management tool to control DRM protection, regardless of whether it's static or dynamic encryption. DRM 加密的输入包括:The inputs for DRM encryption include:

  • MBR 视频内容MBR video content
  • 内容密钥Content key
  • 许可证获取 URLLicense acquisition URLs

在播放期间,高级流程是:Here's the high-level flow during playback time:

  • 对用户进行身份验证。The user is authenticated.
  • 为用户创建授权令牌。An authorization token is created for the user.
  • 将 DRM 保护的内容(清单)下载到播放器。DRM protected content (manifest) is downloaded to the player.
  • 播放器将许可证获取请求和密钥 ID 与授权令牌提交到许可证服务器。The player submits a license acquisition request to license servers together with a key ID and an authorization token.

以下部分介绍密钥管理的设计。The following section discusses the design of key management.

ContentKey-to-assetContentKey-to-asset 方案Scenario
一对一1-to-1 最简单的情况。The simplest case. 它提供最精细的控制。It provides the finest control. 但是,此排列方式通常产生最高的许可证传送成本。But this arrangement generally results in the highest license delivery cost. 每个受保护的资产需要至少一个许可证请求。At minimum, one license request is required for each protected asset.
一对多1-to-many 可以对多个资产使用相同的内容密钥。You could use the same content key for multiple assets. 例如,对于如流派或流派子集(或电影基因)的逻辑组中的所有资产,可以使用单个内容密钥。For example, for all the assets in a logical group, such as a genre or the subset of a genre (or movie gene), you can use a single content key.
多对一Many-to-1 每个资产需要多个内容密钥。Multiple content keys are needed for each asset.

例如,如果需要针对 MPEG-DASH 应用具有多重 DRM 的动态 CENC 保护,且针对 HLS 应用动态 AES-128 加密,则需要两个单独的内容密钥。For example, if you need to apply dynamic CENC protection with multi-DRM for MPEG-DASH and dynamic AES-128 encryption for HLS, you need two separate content keys. 每个内容密钥有自身的 ContentKeyType。Each content key needs its own ContentKeyType. (对于用于动态 CENC 保护的内容密钥,应使用 ContentKeyType.CommonEncryption。(For the content key used for dynamic CENC protection, use ContentKeyType.CommonEncryption. 对于用于动态 AES-128 加密的内容密钥,应使用 ContentKeyType.EnvelopeEncryption。)For the content key used for dynamic AES-128 encryption, use ContentKeyType.EnvelopeEncryption.)

再举一个示例,在 DASH 内容的 CENC 保护中,从理论上讲,可以使用一个内容密钥来保护视频流,以及使用另一个内容密钥来保护音频流。As another example, in CENC protection of DASH content, in theory, you can use one content key to protect the video stream and another content key to protect the audio stream.
多对多Many-to-many 结合上述两种方案。Combination of the previous two scenarios. 对于相同数据“组”中的每个多重资产,使用一组内容密钥。One set of content keys is used for each of the multiple assets in the same asset group.

另一个需要考虑的重要因素是持久性和非持续久许可证的使用。Another important factor to consider is the use of persistent and nonpersistent licenses.

为何这些考虑因素非常重要?Why are these considerations important?

如果针对许可证传送使用公有云,持久性和非持久性许可证对于许可证传送成本有直接影响。If you use a public cloud for license delivery, persistent and nonpersistent licenses have a direct impact on license delivery cost. 下面演示了两种不同的设计方案:The following two different design cases serve to illustrate:

  • 每月订阅:使用永久性许可证,以及一对多内容密钥到资产映射。Monthly subscription: Use a persistent license and 1-to-many content key-to-asset mapping. 例如,对于所有儿童影片,使用单个内容密钥进行加密。For example, for all the kids' movies, we use a single content key for encryption. 在这种情况下:In this case:

    所有儿童影片/设备的许可证总数 = 1Total number of licenses requested for all kids' movies/device = 1

  • 每月订阅:在内容密钥与资产之间使用非永久性许可证以及一对一映射。Monthly subscription: Use a nonpersistent license and 1-to-1 mapping between content key and asset. 在这种情况下:In this case:

    所有儿童影片/设备的许可证总数 = [观看影片数] x [会话数]Total number of licenses requested for all kids' movies/device = [number of movies watched] x [number of sessions]

两种不同的设计会导致大不相同的许可证请求模式。The two different designs result in very different license request patterns. 如果许可证传送服务由 Azure 媒体服务等公有云提供,则不同的模式会造成许可证传送成本不同。The different patterns result in different license delivery cost if license delivery service is provided by a public cloud such as Media Services.

将设计映射到技术以供实现Map design to technology for implementation

接下来,通过指定用于每个构建基块的技术,将常规设计映射到 Azure/媒体服务平台上的技术。Next, the generic design is mapped to technologies on the Azure/Media Services platform by specifying which technology to use for each building block.

下表显示了映射。The following table shows the mapping.

构建基块Building block 技术Technology
播放器Player Azure Media PlayerAzure Media Player
标识提供者 (IDP)Identity provider (IDP) Azure Active Directory (Azure AD)Azure Active Directory (Azure AD)
安全令牌服务 (STS)Security token service (STS) Azure ADAzure AD
DRM 保护工作流DRM protection workflow 媒体服务动态保护Media Services dynamic protection
DRM 许可证传送DRM license delivery * 媒体服务许可证传送(PlayReady、FairPlay)* Media Services license delivery (PlayReady, FairPlay)
* Axinom 许可证服务器* Axinom license server
* 自定义 PlayReady 许可证服务器* Custom PlayReady license server
Origin 媒体服务流式处理终结点Media Services streaming endpoint
密钥管理Key management 不需要参考实现Not needed for reference implementation
内容管理Content management 一个 C# 控制台应用程序A C# console application

换而言之,IDP 和 STS 都将与 Azure AD 配合使用。In other words, both IDP and STS are used with Azure AD. Azure 媒体播放器 API 用于播放器。The Azure Media Player API is used for the player. 媒体服务和媒体播放器都支持具有多重 DRM 的 DASH 和 CENC。Both Media Services and Media Player support DASH and CENC with multi-DRM.

下图显示了上述技术映射的整体结构与流程。The following diagram shows the overall structure and flow with the previous technology mapping:

媒体服务中的 CENC

为了设置动态 CENC 加密,内容管理工具将使用以下输入:To set up dynamic CENC encryption, the content management tool uses the following inputs:

  • 公开的内容Open content
  • 来自密钥生成/管理的内容密钥Content key from key generation/management
  • 许可证获取 URLLicense acquisition URLs
  • Azure AD 中的信息列表A list of information from Azure AD

内容管理工具的输出如下:Here's the output of the content management tool:

  • ContentKeyAuthorizationPolicy,包含有关许可证传送如何验证 JSON Web 令牌 (JWT) 令牌和 DRM 许可证规范的规范。ContentKeyAuthorizationPolicy contains the specification on how license delivery verifies a JSON Web Token (JWT) and DRM license specifications.
  • AssetDeliveryPolicy,包含有关流格式、DRM 保护和许可证获取 URL 的规范。AssetDeliveryPolicy contains specifications on streaming format, DRM protection, and license acquisition URLs.

在运行时,流如下:Here's the flow during runtime:

  • 对用户进行身份验证后,生成 JWT。Upon user authentication, a JWT is generated.
  • JWT 中包含的声明之一是 groups 声明,其中包含 EntitledUserGroup 的组对象 ID。One of the claims contained in the JWT is a groups claim that contains the group object ID EntitledUserGroup. 此声明用于传递权利检查。This claim is used to pass the entitlement check.
  • 播放器下载 CENC 保护内容的客户端清单,并可以识别以下信息:The player downloads the client manifest of CENC-protected content and identifies the following:
    • 密钥 ID。Key ID.
    • 内容受 CENC 保护。The content is CENC protected.
    • 许可证获取 URL。License acquisition URLs.
  • 播放器根据支持的浏览器/DRM 发出许可证获取请求。The player makes a license acquisition request based on the browser/DRM supported. 在许可证获取请求中,还会提交密钥 ID 和 JWT。In the license acquisition request, the key ID and the JWT are also submitted. 许可证传送服务会验证 JWT,在颁发所需的许可证之前包含声明。The license delivery service verifies the JWT and the claims contained before it issues the needed license.

实现Implementation

实现过程Implementation procedures

实现包括下列步骤:Implementation includes the following steps:

  1. 准备测试资产。Prepare test assets. 将测试视频编码/打包为媒体服务中的多比特率分段 MP4。Encode/package a test video to multi-bitrate fragmented MP4 in Media Services. 此资产不受 DRM 保护。 This asset is not DRM protected. DRM 保护稍后由动态保护完成。DRM protection is done by dynamic protection later.

  2. 创建密钥 ID 和内容密钥(可以选择从密钥种子中获取)。Create a key ID and a content key (optionally from a key seed). 在此情况下,不需要密钥管理系统,因为只需要对一些测试资产使用单个密钥 ID 和内容密钥。In this instance, the key management system isn't needed because only a single key ID and content key are required for a couple of test assets.

  3. 使用媒体服务 API 来对测试资产配置多重 DRM 许可证传送服务。Use the Media Services API to configure multi-DRM license delivery services for the test asset. 如果使用公司或公司供应商的自定义许可证服务器,而不是媒体服务中的许可证服务,则可以跳过此步骤。If you use custom license servers by your company or your company's vendors instead of license services in Media Services, you can skip this step. 在配置许可证传送的步骤中,可以指定许可证获取 URL。You can specify license acquisition URLs in the step when you configure license delivery. 需要使用媒体服务 API 指定一些详细配置,例如不同 DRM 许可证服务的许可证策略限制和许可证响应模板。The Media Services API is needed to specify some detailed configurations, such as authorization policy restriction and license response templates for different DRM license services. 目前,Azure 门户尚未提供此配置所需的 UI。At this time, the Azure portal doesn't provide the needed UI for this configuration. 有关 API 级别信息和示例代码,请参阅使用 PlayReady 动态通用加密For API-level information and sample code, see Use PlayReady dynamic common encryption.

  4. 使用媒体服务 API 针对测试资产配置资产传送策略。Use the Media Services API to configure the asset delivery policy for the test asset. 有关 API 级别信息和示例代码,请参阅使用 PlayReady 动态通用加密For API-level information and sample code, see Use PlayReady dynamic common encryption.

  5. 在 Azure 中创建和配置 Azure AD 租户。Create and configure an Azure AD tenant in Azure.

  6. 在 Azure AD 租户中创建一些用户帐户和组。Create a few user accounts and groups in your Azure AD tenant. 至少创建一个“已获授权用户”组,并将一个用户添加到此组。Create at least an "Entitled User" group, and add a user to this group. 在许可证获取过程中,此组中的用户可以通过权利检查。Users in this group pass the entitlement check in license acquisition. 此组中的用户无法通过身份验证检查,且无法获取许可证。Users not in this group fail to pass the authentication check and can't acquire a license. 在 Azure AD 颁发的 JWT 中的 groups 声明中必须使用此“已获授权用户”组的成员身份。Membership in this "Entitled User" group is a required groups claim in the JWT issued by Azure AD. 配置多重 DRM 许可证传送服务时,可以在步骤中指定此声明要求。You specify this claim requirement in the step when you configure multi-DRM license delivery services.

  7. 创建 ASP.NET MVC 应用,用于托管视频播放器。Create an ASP.NET MVC app to host your video player. 此 ASP.NET 应用根据 Azure AD 租户受到用户身份验证的保护。This ASP.NET app is protected with user authentication against the Azure AD tenant. 对用户进行身份验证后,适当的声明将包含在获取的访问令牌中。Proper claims are included in the access tokens obtained after user authentication. 我们建议在此步骤中使用 OpenID Connect API。We recommend OpenID Connect API for this step. 安装以下 NuGet 包:Install the following NuGet packages:

    • Install-Package Microsoft.Azure.ActiveDirectory.GraphClientInstall-Package Microsoft.Azure.ActiveDirectory.GraphClient
    • Install-Package Microsoft.Owin.Security.OpenIdConnectInstall-Package Microsoft.Owin.Security.OpenIdConnect
    • Install-Package Microsoft.Owin.Security.CookiesInstall-Package Microsoft.Owin.Security.Cookies
    • Install-Package Microsoft.Owin.Host.SystemWebInstall-Package Microsoft.Owin.Host.SystemWeb
    • Install-Package Microsoft.IdentityModel.Clients.ActiveDirectoryInstall-Package Microsoft.IdentityModel.Clients.ActiveDirectory
  8. 使用 Azure 媒体播放器 API 创建播放器。Create a player by using the Azure Media Player API. 通过 Azure 媒体播放器的 ProtectionInfo API 指定要在不同的 DRM 平台上使用哪种 DRM 技术。Use the Azure Media Player ProtectionInfo API to specify which DRM technology to use on different DRM platforms.

  9. 下表显示了测试矩阵。The following table shows the test matrix.

    DRMDRM 浏览器Browser 已获授权用户的结果Result for entitled user 未获授权用户的结果Result for unentitled user
    PlayReadyPlayReady Windows 10 上的 Microsoft Edge 或 Internet Explorer 11Microsoft Edge or Internet Explorer 11 on Windows 10 成功Succeed 失败Fail
    FairPlayFairPlay macOS 上的 SafariSafari on macOS 成功Succeed 失败Fail
    AES-128AES-128 大多数新式浏览器Most modern browsers 成功Succeed 失败Fail

有关针对 ASP.NET MVC 播放器应用配置 Azure AD 的信息,请参阅将基于 Azure 媒体服务 OWIN MVC 的应用与 Azure Active Directory 相集成,并基于 JWT 声明限制内容密钥传送For information on how to set up Azure AD for an ASP.NET MVC player app, see Integrate an Azure Media Services OWIN MVC-based app with Azure Active Directory and restrict content key delivery based on JWT claims.

有关详细信息,请参阅 Azure 媒体服务和动态加密中的 JWT 令牌身份验证For more information, see JWT token authentication in Azure Media Services and dynamic encryption.

有关 Azure AD 的信息:For information on Azure AD:

实现中的一些问题Some issues in implementation

请使用以下故障排除信息来帮助解决实现问题。Use the following troubleshooting information for help with implementation issues.

  • 颁发者 URL 必须以“/”结尾。The issuer URL must end with "/". 受众必须是播放器应用程序客户端 ID。The audience must be the player application client ID. 此外,必须在颁发者 URL 的末尾添加“/”。Also, add "/" at the end of the issuer URL.

      <add key="ida:audience" value="[Application Client ID GUID]" />
      <add key="ida:issuer" value="https://sts.chinacloudapi.cn/[AAD Tenant ID]/" />
    

    JWT 解码器中,可以看到 JWT 中所示的 audissIn the JWT Decoder, you see aud and iss, as shown in the JWT:

    JWT

  • 在应用程序的“配置”选项卡上,将权限添加到 Azure AD 中的应用程序。 Add permissions to the application in Azure AD on the Configure tab of the application. 对于本地版本和已部署的版本,需要提供每个应用程序的权限。Permissions are required for each application, both local and deployed versions.

    权限

  • 设置动态 CENC 保护时,请使用正确的颁发者。Use the correct issuer when you set up dynamic CENC protection.

      <add key="ida:issuer" value="https://sts.chinacloudapi.cn/[AAD Tenant ID]/"/>
    

    以下代码无法运行:The following doesn't work:

      <add key="ida:issuer" value="https://willzhanad.partner.onmschina.cn/" />
    

    GUID 是 Azure AD 租户 ID。The GUID is the Azure AD tenant ID. 可以在 Azure 门户上的“终结点”弹出菜单中找到该 GUID。 The GUID can be found in the Endpoints pop-up menu in the Azure portal.

  • 授予组成员资格声明权限。Grant group membership claims privileges. 确保 Azure AD 应用程序清单文件中包含以下内容:Make sure the following is in the Azure AD application manifest file:

    "groupMembershipClaims": "All"(默认值为 null)"groupMembershipClaims": "All" (the default value is null)

  • 创建限制要求时,请设置适当的 TokenType。Set the proper TokenType when you create restriction requirements.

      objTokenRestrictionTemplate.TokenType = TokenType.JWT;
    

    由于除了 JWT (ACS) 以外,还添加了对 SWT (Azure AD) 的支持,因此默认 TokenType 是 TokenType.JWT。Because you add support for JWT (Azure AD) in addition to SWT (ACS), the default TokenType is TokenType.JWT. 如果使用 SWT/ACS,则必须将令牌设置为 TokenType.SWT。If you use SWT/ACS, you must set the token to TokenType.SWT.

有关实现的其他主题Additional topics for implementation

本部分讨论设计和实现中的一些其他主题。This section discusses some additional topics in design and implementation.

使用 HTTP 还是 HTTPS?HTTP or HTTPS?

构建的 ASP.NET MVC 播放器应用程序必须支持以下功能:The ASP.NET MVC player application must support the following:

  • 通过 Azure AD 进行用户身份验证(使用 HTTPS)。User authentication through Azure AD, which is under HTTPS.
  • 客户端与 Azure AD 之间的 JWT 交换(使用 HTTPS)。JWT exchange between the client and Azure AD, which is under HTTPS.
  • 客户端的 DRM 许可证获取,如果许可证传送由媒体服务提供(必须使用 HTTPS)。DRM license acquisition by the client, which must be under HTTPS if license delivery is provided by Media Services. PlayReady 产品套件不会针对许可证传送强制要求使用 HTTPS。The PlayReady product suite doesn't mandate HTTPS for license delivery. 如果 PlayReady 许可证服务器位于媒体服务以外的地方,则可以使用 HTTP 或 HTTPS。If your PlayReady license server is outside Media Services, you can use either HTTP or HTTPS.

最佳做法是让 ASP.NET 播放器应用程序使用 HTTPS,使媒体播放器位于使用 HTTPS 的页面上。The ASP.NET player application uses HTTPS as a best practice, so Media Player is on a page under HTTPS. 不过,最好是使用 HTTP 进行流式传输,因此需要考虑混合内容问题。However, HTTP is preferred for streaming, so you need to consider the issue of mixed content.

  • 浏览器不允许混合内容。The browser doesn't allow mixed content. 但是 Silverlight 等插件和适用于平滑流与 DASH 的 OSMF 插件允许混合内容。But plug-ins like Silverlight and the OSMF plug-in for smooth and DASH do allow it. 混合内容存在安全隐患 - 因为能够插入恶意 JavaScript 威胁,从而使客户数据处于风险之中。Mixed content is a security concern because of the threat of the ability to inject malicious JavaScript, which can cause customer data to be at risk. 默认情况下,浏览器会阻止此类内容。Browsers block this capability by default. 唯一的解决方法是在服务器(来源)端允许所有域(不管是 HTTPS 还是 HTTP)。The only way to work around it is on the server (origin) side by allowing all domains (regardless of HTTPS or HTTP). 这可能也不是个好主意。This is probably not a good idea either.
  • 避免混合内容。Avoid mixed content. 播放器应用程序和媒体播放器应使用 HTTP 或 HTTPS。Both the player application and Media Player should use HTTP or HTTPS. 播放混合内容时,silverlightSS 技术需要清除混合内容警告。When playing mixed content, the silverlightSS tech requires clearing a mixed-content warning. flashSS 技术在没有混合内容警告的情况下处理混合内容。The flashSS tech handles mixed content without a mixed-content warning.
  • 如果流式处理终结点是在 2014 年 8 月之前创建的,则它不支持 HTTPS。If your streaming endpoint was created before August 2014, it won't support HTTPS. 在此情况下,请针对 HTTPS 创建并使用新的流式处理终结点。In this case, create and use a new streaming endpoint for HTTPS.

在参考实现中,对于 DRM 保护内容,应用程序和流都使用 HTTPS。In the reference implementation for DRM-protected contents, both the application and streaming are under HTTPS. 对于打开的内容,播放器不需要身份验证或许可证,因此可以使用 HTTP 或 HTTPS。For open contents, the player doesn't need authentication or a license, so you can use either HTTP or HTTPS.

Azure Active Directory 签名密钥滚动更新Azure Active Directory signing key rollover

密钥滚动更新是需要在实现中考虑的要点。Signing key rollover is an important point to take into consideration in your implementation. 如果忽略它,已完成的系统最终会在最多六周之后完全停止运行。If you ignore it, the finished system eventually stops working completely, within six weeks at the most.

Azure AD 使用行业标准,通过 Azure AD 在本身与应用程序之间建立信任。Azure AD uses industry standards to establish trust between itself and applications that use Azure AD. 具体而言,Azure AD 使用签名密钥,该密钥由公钥和私钥对组成。Specifically, Azure AD uses a signing key that consists of a public and private key pair. 当 Azure AD 创建包含用户相关信息的安全令牌时,Azure AD 将使用私钥对此令牌进行签名,然后将令牌发回给应用程序。When Azure AD creates a security token that contains information about the user, it's signed by Azure AD with a private key before it's sent back to the application. 若要验证该令牌是否有效且来自 Azure AD,应用程序验证令牌的签名。To verify that the token is valid and originated from Azure AD, the application must validate the token's signature. 应用程序可以使用由 Azure AD 公开且包含在租户联合元数据文档中的公钥。The application uses the public key exposed by Azure AD that is contained in the tenant's federation metadata document. 此公钥以及衍生它的签名密钥是由 Azure AD 中所有租户使用的同一个密钥。This public key, and the signing key from which it derives, is the same one used for all tenants in Azure AD.

有关 Azure AD 密钥滚动更新的详细信息,请参阅有关 Azure AD 中签名密钥滚动更新的重要信息For more information on Azure AD key rollover, see Important information about signing key rollover in Azure AD.

公钥-私钥对之间:Between the public-private key pair:

  • Azure AD 使用私钥生成 JWT。The private key is used by Azure AD to generate a JWT.
  • 应用程序(例如媒体服务中的 DRM 许可证传送服务)使用公钥验证 JWT。The public key is used by an application such as DRM license delivery services in Media Services to verify the JWT.

出于安全目的,Azure AD 将定期轮换证书(每隔六周)。For security purposes, Azure AD rotates the certificate periodically (every six weeks). 在发生安全违规时,密钥滚动更新可随时发生。In the case of security breaches, the key rollover can occur any time. 因此,媒体服务中的许可证传送服务需要在 Azure AD 轮换密钥对时更新公钥。Therefore, the license delivery services in Media Services need to update the public key used as Azure AD rotates the key pair. 否则媒体服务中的令牌身份验证会失败,并且不颁发任何许可证。Otherwise, token authentication in Media Services fails and no license is issued.

若要设置此服务,可以在配置 DRM 许可证传送服务时设置 TokenRestrictionTemplate.OpenIdConnectDiscoveryDocument。To set up this service, you set TokenRestrictionTemplate.OpenIdConnectDiscoveryDocument when you configure DRM license delivery services.

下面是 JWT 流:Here's the JWT flow:

  • Azure AD 使用当前私钥为已经过身份验证的用户颁发 JWT。Azure AD issues the JWT with the current private key for an authenticated user.
  • 当播放器看到使用多重 DRM 的 CENC 保护的内容时,会先找到 Azure AD 颁发的 JWT。When a player sees a CENC with multi-DRM protected content, it first locates the JWT issued by Azure AD.
  • 播放器将包含 JWT 的许可证获取请求发送到媒体服务中的许可证传送服务。The player sends a license acquisition request with the JWT to license delivery services in Media Services.
  • 媒体服务中的许可证传送服务使用来自 Azure AD 的当前/有效公钥来验证 JWT,并颁发许可证。The license delivery services in Media Services use the current/valid public key from Azure AD to verify the JWT before issuing licenses.

DRM 许可证传送服务始终会检查来自 Azure AD 的当前/有效公钥。DRM license delivery services always check for the current/valid public key from Azure AD. Azure AD 提供的公钥是用于验证 Azure AD 所颁发 JWT 的密钥。The public key presented by Azure AD is the key used to verify a JWT issued by Azure AD.

如果 Azure AD 生成 JWT 之后、播放器将 JWT 发送到媒体服务中的 DRM 许可证传送服务以进行验证之前发生密钥滚动更新,会怎么样?What if the key rollover happens after Azure AD generates a JWT but before the JWT is sent by players to DRM license delivery services in Media Services for verification?

由于密钥可能在任何时间滚动更新,联合元数据文档中始终有多个有效公钥可用。Because a key can be rolled over at any moment, more than one valid public key is always available in the federation metadata document. 媒体服务许可证传送可以使用文档中指定的任何密钥。Media Services license delivery can use any of the keys specified in the document. 因为一个密钥可能很快就被轮换为另一个密钥。Because one key might be rolled soon, another might be its replacement, and so forth.

访问令牌位于何处?Where is the access token?

如果在带有 OAuth 2.0 客户端凭据授予的应用程序标识下,Web 应用调用 API 应用,身份验证流如下:If you look at how a web app calls an API app under Application identity with OAuth 2.0 client credentials grant, the authentication flow is as follows:

  • 用户在 Web 应用程序中登录到 Azure AD。A user signs in to Azure AD in the web application. 有关详细信息,请参阅 Web 浏览器到 Web 应用程序For more information, see Web browser to web application.
  • Azure AD 许可证终结点使用授权代码将用户代理重定向回到客户端应用程序。The Azure AD authorization endpoint redirects the user agent back to the client application with an authorization code. 用户代理将授权代码返回给客户端应用程序的重定向 URI。The user agent returns the authorization code to the client application's redirect URI.
  • Web 应用程序需要获取访问令牌,以便通过 Web API 进行身份验证并检索所需的资源。The web application needs to acquire an access token so that it can authenticate to the web API and retrieve the desired resource. 它向 Azure AD 的令牌终结点发出一个请求,在其中提供凭据、客户端 ID 以及 Web API 的应用程序 ID URI。It makes a request to the Azure AD token endpoint and provides the credential, client ID, and web API's application ID URI. 它将提供授权代码来证明已获得用户许可。It presents the authorization code to prove that the user consented.
  • Azure AD 对应用程序进行身份验证并返回用来调用 Web API 的 JWT 访问令牌。Azure AD authenticates the application and returns a JWT access token that's used to call the web API.
  • 通过 HTTPS,Web 应用程序使用返回的 JWT 访问令牌在发往 Web API 的请求的“Authorization”标头中添加一个具有“Bearer”限定符的 JWT 字符串。Over HTTPS, the web application uses the returned JWT access token to add the JWT string with a "Bearer" designation in the "Authorization" header of the request to the web API. 然后,Web API 对 JWT 进行验证。The web API then validates the JWT. 如果验证成功,则返回所需的资源。If validation is successful, it returns the desired resource.

在此应用程序标识流中,Web API 相信 Web 应用程序已对用户进行了身份验证。In this application identity flow, the web API trusts that the web application authenticated the user. 因此,此模式称为受信任的子系统。For this reason, this pattern is called a trusted subsystem. 授权流示意图描绘了授权代码授予流的工作原理。The authorization flow diagram describes how authorization-code-grant flow works.

在具有令牌限制的许可证获取中,遵循相同的受信任子系统模式。License acquisition with token restriction follows the same trusted subsystem pattern. 媒体服务中的许可证传送服务是 Web API 资源,即 Web 应用程序需要访问的“后端资源”。The license delivery service in Media Services is the web API resource, or the "back-end resource" that a web application needs to access. 那么,访问令牌位于何处?So where is the access token?

访问令牌是是从 Azure AD 获取的。The access token is obtained from Azure AD. 成功完成用户身份验证后,将返回授权代码。After successful user authentication, an authorization code is returned. 然后使用授权代码连同客户端 ID 和应用密钥来交换访问令牌。The authorization code is then used, together with the client ID and the app key, to exchange for the access token. 访问令牌用于访问指向或代表媒体服务许可证传送服务的“指针”应用程序。The access token is used to access a "pointer" application that points to or represents the Media Services license delivery service.

若要在 Azure AD 中注册并配置指针应用,请执行以下步骤:To register and configure the pointer app in Azure AD, take the following steps:

  1. 在 Azure AD 租户中:In the Azure AD tenant:

    • 添加具有登录 URL“https://[resource_name].chinacloudsites.cn/”的应用程序(资源)。Add an application (resource) with the sign-on URL https://[resource_name].chinacloudsites.cn/.
    • 添加应用 ID 与 URL https://[AAD 租户名称].partner.onmschina.cn/[资源名称]。Add an app ID with the URL https://[aad_tenant_name].partner.onmschina.cn/[resource_name].
  2. 为资源应用添加新的密钥。Add a new key for the resource app.

  3. 更新应用程序清单文件,使 groupMembershipClaims 属性具有值 "groupMembershipClaims": "All"。Update the app manifest file so that the groupMembershipClaims property has the value "groupMembershipClaims": "All".

  4. 在指向播放器 Web 应用的 Azure AD 应用中,在“对其他应用程序的权限”部分添加步骤 1 中添加的资源应用。 In the Azure AD app that points to the player web app, in the section Permissions to other applications, add the resource app that was added in step 1. 在“委派权限”下面选择“访问 [资源名称]”。 Under Delegated permission, select Access [resource_name]. 此选项可授予 Web 应用创建访问令牌的权限以访问资源应用。This option gives the web app permission to create access tokens that access the resource app. 如果使用 Visual Studio 和 Azure Web 应用进行开发,请对本地版本和已部署版本的 Web 应用执行此操作。Do this for both the local and deployed version of the web app if you develop with Visual Studio and the Azure web app.

Azure AD 颁发的 JWT 是用于访问此指针资源的访问令牌。The JWT issued by Azure AD is the access token used to access the pointer resource.

如何使用实时流?What about live streaming?

前面的讨论内容将重点放在按需资产上。The previous discussion focused on on-demand assets. 如何使用实时流?What about live streaming?

可以使用完全相同的设计和实现来保护媒体服务中的实时传送视频流,方法是将与节目关联的资产视为 VOD 资产。You can use exactly the same design and implementation to protect live streaming in Media Services by treating the asset associated with a program as a VOD asset.

具体而言,要在媒体服务中执行实时传送视频流,需要创建频道,并在频道下面创建节目。Specifically, to do live streaming in Media Services, you need to create a channel and then create a program under the channel. 若要创建节目,需要创建资产并在其中包含节目的实时存档。To create the program, you need to create an asset that contains the live archive for the program. 要使用带有多重 DRM 的 CENC 来保护实时内容,可在启动节目之前将相同设置/处理应用到资产,就如同它是 VOD 资产一样。To provide CENC with multi-DRM protection of the live content, apply the same setup/processing to the asset as if it were a VOD asset before you start the program.

如何使用媒体服务外部的许可证服务器?What about license servers outside Media Services?

通常,客户可能已在他们自己的数据中心或由 DRM 服务提供商托管的位置投资了许可证服务器场。Often, customers invested in a license server farm either in their own data center or one hosted by DRM service providers. 使用媒体服务内容保护,可以在混合模式下操作。With Media Services Content Protection, you can operate in hybrid mode. 可以在媒体服务中托管和动态保护内容,而 DRM 许可证由 Azure 媒体服务外部的服务器传送。Contents can be hosted and dynamically protected in Media Services, while DRM licenses are delivered by servers outside Media Services. 在此情况下,请注意以下变更:In this case, consider the following changes:

  • STS 需要颁发被许可证服务器场认可和验证的令牌。STS needs to issue tokens that are acceptable and can be verified by the license server farm.
  • 不再需要在媒体服务中配置许可证传送服务 (ContentKeyAuthorizationPolicy)。You no longer need to configure license delivery service (ContentKeyAuthorizationPolicy) in Media Services. 配置 AssetDeliveryPolicy 以使用多重 DRM 设置 CENC 时,需要提供许可证获取 URL(用于 PlayReady 和 FairPlay)。You need to provide the license acquisition URLs (for PlayReady and FairPlay) when you configure AssetDeliveryPolicy to set up CENC with multi-DRM.

如何使用自定义 STS?What if I want to use a custom STS?

客户可能想要使用自定义 STS 来提供 JWT。A customer might choose to use a custom STS to provide JWTs. 原因包括:Reasons include:

  • 客户使用的 IDP 不支持 STS。The IDP used by the customer doesn't support STS. 在此情况下,可以选择自定义 STS。In this case, a custom STS might be an option.
  • 客户在集成 STS 与客户的订户计费系统时可能需要更多弹性或更紧密的控制。The customer might need more flexible or tighter control to integrate STS with the customer's subscriber billing system. 例如,MVPD 运营商可能提供多个 OTT 订户套餐,如高级、基本和运动。For example, an MVPD operator might offer multiple OTT subscriber packages, such as premium, basic, and sports. 运营商可能想要让令牌中的声明与订户套餐匹配,这样,只有特定套餐中的内容可供使用。The operator might want to match the claims in a token with a subscriber's package so that only the contents in a specific package are made available. 在此情况下,自定义 STS 可提供所需的弹性和控制度。In this case, a custom STS provides the needed flexibility and control.

使用自定义 STS 时,必须进行两项更改:When you use a custom STS, two changes must be made:

  • 为资产配置许可证传送服务时,需要指定自定义 STS 用于验证的安全密钥,而不是来自 Azure AD 的当前密钥。When you configure license delivery service for an asset, you need to specify the security key used for verification by the custom STS instead of the current key from Azure AD. (下面提供了详细信息。)(More details follow.)
  • 生成 JTW 令牌时,需要指定安全密钥,而不是 Azure AD 中当前 X509 证书的私钥。When a JTW token is generated, a security key is specified instead of the private key of the current X509 certificate in Azure AD.

有两种类型的安全密钥:There are two types of security keys:

  • 对称密钥:使用同一密钥来生成和验证 JWT。Symmetric key: The same key is used to generate and to verify a JWT.
  • 非对称密钥:使用 X509 证书中的私钥-公钥对,私钥用于加密/生成 JWT,公钥用于验证令牌。Asymmetric key: A public-private key pair in an X509 certificate is used with a private key to encrypt/generate a JWT and with the public key to verify the token.

备注

如果使用 .NET Framework/C# 作为开发平台,用于非对称安全密钥的 X509 证书的密钥长度必须至少为 2048。If you use .NET Framework/C# as your development platform, the X509 certificate used for an asymmetric security key must have a key length of at least 2048. 这是 .NET Framework 中 System.IdentityModel.Tokens.X509AsymmetricSecurityKey 类的要求。This is a requirement of the class System.IdentityModel.Tokens.X509AsymmetricSecurityKey in .NET Framework. 否则,将引发以下异常:Otherwise, the following exception is thrown:

IDX10630: 用于签名的 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey' 不能小于 '2048' 位。IDX10630: The 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey' for signing cannot be smaller than '2048' bits.

完成的系统和测试The completed system and test

本部分逐步讲解如何在完成的端到端系统中完成以下方案,让读者在获取登录帐户之前对该行为有个基本印象。This section walks you through the following scenarios in the completed end-to-end system so that you can have a basic picture of the behavior before you get a sign-in account:

  • 如需非集成式方案:If you need a non-integrated scenario:

    • 托管在媒体服务中的视频资产未受保护或受 DRM 保护,但是没有令牌身份验证(对任何提出请求的对象颁发许可证),可以测试它而不用登录。For video assets hosted in Media Services that are either unprotected or DRM protected but without token authentication (issuing a license to whoever requested it), you can test it without signing in. 如果视频是通过 HTTP 流式传输的,请切换到 HTTP。Switch to HTTP if your video streaming is over HTTP.
  • 如果需要端到端集成方案:If you need an end-to-end integrated scenario:

    • 视频资产在媒体服务中受动态 DRM 的保护,并且令牌身份验证与 JWT 由 Azure AD 生成,则需要登录。For video assets under dynamic DRM protection in Media Services, with the token authentication and JWT generated by Azure AD, you need to sign in.

对于播放器 Web 应用程序及其登录,请参阅此网站For the player web application and its sign-in, see this website.

用户登录User sign-in

为了测试端到端集成 DRM 系统,需要创建或添加一个帐户。To test the end-to-end integrated DRM system, you need to have an account created or added.

什么帐户?What account?

尽管 Azure 最初只允许 Microsoft 帐户用户的访问,但现在它允许来自两个系统的用户的访问。Although Azure originally allowed access only by Microsoft account users, access is now allowed by users from both systems. 所有 Azure 属性现在都信任 Azure AD 执行身份验证,Azure AD 将对组织用户进行身份验证。All Azure properties now trust Azure AD for authentication, and Azure AD authenticates organizational users. 已创建一种联合关系,在这种关系中,Azure AD 信任 Microsoft 帐户使用者标识系统对使用者用户执行身份验证。A federation relationship was created where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. 因此,Azure AD 能够对来宾 Microsoft 帐户以及本机 Azure AD 帐户进行身份验证。As a result, Azure AD can authenticate guest Microsoft accounts as well as native Azure AD accounts.

由于 Azure AD 信任 Microsoft 帐户域,因此可以将以下任何域的任何帐户添加到自定义 Azure AD 租户,并使用该帐户登录:Because Azure AD trusts the Microsoft account domain, you can add any accounts from any of the following domains to the custom Azure AD tenant and use the account to sign in:

域名Domain name Domain
自定义 Azure AD 租户域Custom Azure AD tenant domain somename.partner.onmschina.cnsomename.partner.onmschina.cn
企业域Corporate domain microsoft.commicrosoft.com
Microsoft 帐户域Microsoft account domain outlook.com、live.com 或 hotmail.comoutlook.com, live.com, hotmail.com

可以联系任何作者来创建或添加帐户。You can contact any of the authors to have an account created or added for you.

以下屏幕截图显示了不同域帐户使用的不同登录页:The following screenshots show different sign-in pages used by different domain accounts:

自定义 Azure AD 租户域帐户:自定义 Azure AD 租户域的自定义登录页。Custom Azure AD tenant domain account: The customized sign-in page of the custom Azure AD tenant domain.

自定义 Azure AD 租户域帐户

采用智能卡的 Microsoft 域帐户:由 Microsoft 公司 IT 部门自定义的、采用双重身份验证的登录页。Microsoft domain account with smart card: The sign-in page customized by Microsoft corporate IT with two-factor authentication.

自定义 Azure AD 租户域帐户

Microsoft 帐户:使用者的 Microsoft 帐户登录页。Microsoft account: The sign-in page of the Microsoft account for consumers.

自定义 Azure AD 租户域帐户

使用 PlayReady 的加密媒体扩展Use Encrypted Media Extensions for PlayReady

在支持 PlayReady 加密媒体扩展 (EME) 的新式浏览器(例如 Windows 8.1 和更高版本上的 Internet Explorer 11,以及 Windows 10 上的 Microsoft Edge 浏览器)上,PlayReady 是 EME 的基本 DRM。On a modern browser with Encrypted Media Extensions (EME) for PlayReady support, such as Internet Explorer 11 on Windows 8.1 or later and Microsoft Edge browser on Windows 10, PlayReady is the underlying DRM for EME.

使用 EME for PlayReady

出现深色播放器区域是因为 PlayReady 保护阻止对受保护的视频进行屏幕截图。The dark player area is because PlayReady protection prevents you from making a screen capture of protected video.

以下屏幕截图显示了播放器插件和 Microsoft Security Essentials (MSE)/EME 支持。The following screenshot shows the player plug-ins and Microsoft Security Essentials (MSE)/EME support:

PlayReady 的播放器插件

Windows 10 上的 Microsoft Edge 和 Internet Explorer 11 中的 EME 允许在支持 PlayReady SL3000 的 Windows 10 设备上调用该技术。EME in Microsoft Edge and Internet Explorer 11 on Windows 10 allows PlayReady SL3000 to be invoked on Windows 10 devices that support it. PlayReady SL3000 解锁增强型高级内容(4K、HDR)以及新的内容传送模型(增强型内容)流程。PlayReady SL3000 unlocks the flow of enhanced premium content (4K, HDR) and new content delivery models (for enhanced content).

将重心放在 Windows 设备上:PlayReady 是 Windows 设备可用的硬件中唯一的 DRM(PlayReady SL3000)。To focus on the Windows devices, PlayReady is the only DRM in the hardware available on Windows devices (PlayReady SL3000). 流式处理服务可通过 EME 或通用 Windows 平台应用程序来使用 PlayReady,并利用 PlayReady SL3000 来提供比其他 DRM 所能提供更高的视频质量。A streaming service can use PlayReady through EME or through a Universal Windows Platform application and offer a higher video quality by using PlayReady SL3000 than another DRM. 一般而言,2K 及更低分辨内容会流经 Chrome 或 Firefox,而 4K 及更低分辨内容流过 Microsoft Edge/Internet Explorer 11 或相同设备上的通用 Windows 平台应用程序。Typically, content up to 2K flows through Chrome or Firefox, and content up to 4K flows through Microsoft Edge/Internet Explorer 11 or a Universal Windows Platform application on the same device. 流量取决于服务设置和实现。The amount depends on service settings and implementation.

未获授权的用户Unentitled users

如果用户不是“已获授权用户”组的成员,则通不过权利检查。If a user isn't a member of the "Entitled Users" group, the user doesn't pass the entitlement check. 多重 DRM 许可证服务将拒绝颁发请求的许可证,如下所述。The multi-DRM license service then refuses to issue the requested license as shown. 详细的说明是“许可证获取失败”,这是设计使然。The detailed description is "License acquire failed," which is as designed.

未获授权的用户

运行自定义安全令牌服务Run a custom security token service

如果运行自定义 STS,JWT 由自定义 STS 使用对称或非对称密钥来颁发。If you run a custom STS, the JWT is issued by the custom STS by using either a symmetric or an asymmetric key.

以下屏幕截图显示了使用对称密钥的方案(使用 Chrome):The following screenshot shows a scenario that uses a symmetric key (using Chrome):

自定义 STS 和对称密钥

以下屏幕截图显示了通过 X509 证书使用非对称密钥的方案(使用 Microsoft 新式浏览器):The following screenshot shows a scenario that uses an asymmetric key via an X509 certificate (using a Microsoft modern browser):

自定义 STS 和非对称密钥

在上述两个方案中,用户身份验证相同。In both of the previous cases, user authentication stays the same. 身份验证是通过 Azure AD 发生的。It takes place through Azure AD. 唯一的差别在于,JWT 由自定义 STS 而不是 Azure AD 颁发。The only difference is that JWTs are issued by the custom STS instead of Azure AD. 配置动态 CENC 保护时,许可证传送服务的限制将指定 JWT 的类型是对称还是非对称密钥。When you configure dynamic CENC protection, the license delivery service restriction specifies the type of JWT, either a symmetric or an asymmetric key.

总结Summary

本文档讨论了使用多重原生 DRM 的 CENC 以及通过令牌身份验证进行访问控制:它的设计和实现使用了 Azure、媒体服务和媒体播放器。This document discussed CENC with multi-native DRM and access control via token authentication, its design, and its implementation by using Azure, Media Services, and Media Player.

  • 文中提供了一个参考设计,其中包含 DRM/CENC 子系统中的所有必要组件。A reference design was presented that contains all the necessary components in a DRM/CENC subsystem.
  • 已提供 Azure、媒体服务和媒体播放器的参考实现。A reference implementation was presented on Azure, Media Services, and Media Player.
  • 同时还讨论了直接涉及到设计和实现的某些主题。Some topics directly involved in the design and implementation were also discussed.

媒体服务学习路径Media Services learning paths

媒体服务 v3(最新版本)Media Services v3 (latest)

查看最新版本的 Azure 媒体服务!Check out the latest version of Azure Media Services!

媒体服务 v2(旧版)Media Services v2 (legacy)