设计带访问控制的多 DRM 内容保护系统Design of a multi-DRM content protection system with access control

媒体服务徽标 v3media services logo v3

针对 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 a reference 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,我们介绍 Azure 媒体服务支持的 2 种 DRM:PlayReady 的通用加密 (CENC)、FairPlay 以及 AES-128 明文密钥加密。In this discussion, by multi-DRM we include the 2 DRMs supported by Azure Media Services: Common Encryption (CENC) for PlayReady, FairPlay as well as AES-128 clear key encryption. 在线流和 OTT 行业中的主要趋势是在各种客户端平台上使用原生 DRM。A major trend in online streaming and the OTT industry is to use native DRMs 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.

使用原生多重 DRM 保护内容的好处包括:The benefits of using native multi-DRM for content protection 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 assets because only a single copy of asset is needed in storage.
  • 消除 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:

  • 提供使用全部两种 DRM 的 DRM 子系统的参考设计(CENC 用于 DASH,FairPlay 用于 HLS,PlayReady 用于实现平滑流式处理)。Provide a reference design of a DRM subsystem that uses the two DRMs (CENC for DASH, FairPlay for HLS and PlayReady for smooth streaming).
  • 提供 Azure 和 Azure 媒体服务平台上的参考实现。Provide a reference implementation on Azure and Azure Media Services platform.
  • 讨论一些设计和实现主题。Discuss some design and implementation topics.

下表总结了不同平台上的原生 DRM 支持和不同浏览器中的 EME 支持。The following table summarizes native DRM support on different platforms and EME support in different browsers.

客户端平台Client platform 原生 DRMNative DRM EMEEME
智能电视、STBSmart TVs, STBs PlayReady 和/或其他PlayReady, and/or other 适用于 PlayReady 的嵌入式浏览器/EMEEmbedded browser/EME for PlayReady
Windows 10Windows 10 PlayReadyPlayReady 适用于 PlayReady 的 Microsoft Edge/IE11Microsoft Edge/IE11 for PlayReady
iOSiOS FairPlayFairPlay 适用于 FairPlay 的 Safari(自 iOS 11.2 起)Safari for FairPlay (since iOS 11.2)
macOSmacOS FairPlayFairPlay 适用于 FairPlay 的 Safari(自 Mac OS X 10.11 + El Capitan 版 Safari 9+ 起)Safari for FairPlay (since Safari 9+ on Mac OS X 10.11+ El Capitan)
tvOStvOS FairPlayFairPlay

就目前每种 DRM 的部署状态而言,服务通常需要实现两到三个 DRM,以确保能以最佳方式处理所有类型的终结点。Considering the current state of deployment for each DRM, a service typically wants to implement two or three 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、macOS 和 tvOS。FairPlay is available on iOS, macOS and tvOS.

参考设计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 encryption packaging
  • DRM 许可证传送DRM license delivery
  • 权利检查/访问控制Entitlement check/access control
  • 用户身份验证/授权User authentication/authorization
  • 播放器应用Player app

下图演示了 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)Secure Token Service (STS) Azure ADAzure AD
DRM 保护工作流DRM protection workflow Azure 媒体服务动态保护Azure 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 Azure 媒体服务流式处理终结点Azure 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 provided by Azure AD. Azure 媒体播放器 API 用于播放器。The Azure Media Player API is used for the player. Azure 媒体服务和 Azure Media Player 通过 DASH 支持 CENC,通过 HLS 支持 FairPlay、通过平滑流式处理支持 PlayReady,并且可对 DASH、HLS 和平滑流式处理进行 AES-128 加密。Both Azure Media Services and Azure Media Player support CENC over DASH, FairPlay over HLS, PlayReady over smooth streaming, and AES-128 encryption for DASH, HLS and smooth.

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

媒体服务中的 CENC

为了设置 DRM 内容加密,内容管理工具使用以下输入:To set up DRM content protection, the content management tool uses the following inputs:

  • 公开的内容Open content
  • 来自密钥管理的内容密钥Content key from key management
  • 许可证获取 URLLicense acquisition URLs
  • Azure AD 中的信息列表,例如受众、证书颁发者和令牌声明A list of information from Azure AD, such as audience, issuer, and token claims

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

  • ContentKeyPolicy 描述用于所用的每种 DRM 的 DRM 许可证模板;ContentKeyPolicy describes DRM license template for each kind of DRM used;
  • ContentKeyPolicyRestriction 描述颁发 DRM 许可证前的访问控制ContentKeyPolicyRestriction describes the access control before a DRM license is issued
  • Streamingpolicy 描述用于流式处理的各种 DRM(加密模式、流式处理协议、容器格式)的组合Streamingpolicy describes the various combinations of DRM - encryption mode - streaming protocol - container format, for streaming
  • StreamingLocator 描述用于加密和流式处理 URL 的内容密钥/IVStreamingLocator describes content key/IV used for encryption, and streaming 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.
    • 内容受 DRM 保护。The content is DRM 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 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:


  • 在应用程序的“配置”选项卡上,将权限添加到 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.

完成的系统和测试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 DomainDomain
自定义 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 租户域帐户 1

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

自定义 Azure AD 租户域帐户 2

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

自定义 Azure AD 租户域帐户 3

使用 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.

使用适用于 FairPlay 的 EMEUse EME for FairPlay

同样,可以在 macOS 或 iOS 11.2 和更高版本 Safari 中,使用此测试播放机测试受 FairPlay 保护的内容。Similarly, you can test FairPlay protected content in this test player in Safari on macOS or iOS 11.2 and later.

请确保使用“FairPlay”作为 protectionInfo.type,并在 FPS AC 路径(FairPlay 流式处理应用程序证书路径)中包含应用程序证书的正确 URL。Make sure you put "FairPlay" as protectionInfo.type and put in the right URL for your Application Certificate in FPS AC Path (FairPlay Streaming Application Certificate Path).

未获授权的用户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.

后续步骤Next steps