CENC con DRM multiplo e controllo di accesso: progettazione di riferimento e implementazione in Azure e in Servizi multimediali di AzureCENC with Multi-DRM and Access Control: A Reference Design and Implementation on Azure and Azure Media Services

IntroduzioneIntroduction

È risaputo che la progettazione e la compilazione di un sottosistema DRM per una soluzione di streaming online o OTT sono attività complesse.It is well known that it is a complex task to design and build a DRM subsystem for an OTT or online streaming solution. Gli operatori e i provider video online in genere danno queste attività in outsourcing a provider di servizi DRM specializzati.And it is a common practice for operators/online video providers to outsource this part to specialized DRM service providers. L'obiettivo di questo documento è presentare una progettazione di riferimento e l'implementazione del sottosistema DRM end-to-end nella soluzione di streaming online o OTT.The goal of this document is to present a reference design and implementation of end-to-end DRM subsystem in OTT or online streaming solution.

Questo documento è destinato agli ingegneri che lavorano nel sottosistema DRM di soluzioni con più schermate/di streaming online o OTT, ma anche a chi è interessato al sottosistema DRM.The targeted readers of this document are engineers working in DRM subsystem of OTT or online streaming/multi-screen solutions, or any readers interested in DRM subsystem. Il presupposto è che i lettori abbiano familiarità con almeno una delle tecnologie DRM presenti sul mercato, ad esempio PlayReady, Widevine, FairPlay o Adobe Access.The assumption is that readers are familiar with at least one of the DRM technologies on the market, such as PlayReady, Widevine, FairPlay or Adobe Access.

DRM include anche CENC (Common Encryption) con DRM multiplo.By DRM, we also include CENC (Common Encryption) with multi-DRM. Una delle tendenze principali del settore OTT e dello streaming online è quella di usare CENC con DRM nativo multiplo su diverse piattaforme client. La tendenza precedente era invece quella di usare un solo DRM e l'SDK client per più piattaforme client.A major trend in online streaming and OTT industry is to use CENC with multi-native-DRM on various client platforms, which is a shift from the previous trend of using a single DRM and its client SDK for various client platforms. Quando si usa CENC con DRM nativo multiplo, PlayReady e Widevine vengono crittografati in base alla specifica Common Encryption (ISO/IEC 23001-7 CENC).When using CENC with multi-native-DRM, both PlayReady and Widevine are encrypted per the Common Encryption (ISO/IEC 23001-7 CENC) specification.

I vantaggi di CENC con DRM multiplo sono i seguenti:The benefits of CENC with multi-DRM are as follows:

  1. Riduce il costo della crittografia perché viene usata una sola elaborazione crittografica per piattaforme diverse con i DRM nativi.Reduces encryption cost since a single encryption processing is used targeting different platforms with its native DRMs;
  2. Riduce il costo della gestione degli asset crittografati perché è necessaria una sola copia degli asset crittografati.Reduces the cost of managing encrypted assets since only a single copy of encrypted assets is needed;
  3. Elimina il costo della licenza del client DRM perché il client DRM nativo è in genere gratuito sulla piattaforma nativa.Eliminates DRM client licensing cost since the native DRM client is usually free on its native platform.

Microsoft, insieme ad alcuni dei principali leader di settore, ha promosso attivamente DASH e CENC.Microsoft has been an active promoter of DASH and CENC together with some major industry players. Servizi multimediali di Microsoft Azure ha fornito il supporto di DASH e CENC.Microsoft Azure Media Services has been providing support of DASH and CENC. Per gli annunci recenti, vedere i blog di Mingfei relativi all'annuncio dell'anteprima pubblica dei servizi di distribuzione delle licenze Google Widevine in Servizi multimediali di Azure e all'aggiunta in Servizi multimediali di Azure del pacchetto Google Widevine per la distribuzione del flusso DRM multiplo.For recent announcements, please see Mingfei’s blogs: Announcing Google Widevine license delivery services in Azure Media Services, and Azure Media Services adds Google Widevine packaging for delivering multi-DRM stream.

Panoramica dell'articoloOverview of this article

Gli obiettivi di questo articolo sono i seguenti:The goal of this article includes the following:

  1. Fornire una progettazione di riferimento del sottosistema DRM usando CENC con DRM multiplo.Provides a reference design of DRM subsystem using CENC with multi-DRM;
  2. Fornire un'implementazione di riferimento nella piattaforma Microsoft Azure/Servizi multimediali di Azure.Provides a reference implementation on Microsoft Azure/Azure Media Services platform;
  3. Illustrare alcuni argomenti relativi alla progettazione e all'implementazione.Discusses some design and implementation topics.

Nell'articolo, "DRM multiplo" fa riferimento a quanto segue:In the article, “multi-DRM” covers the following:

  1. Microsoft PlayReadyMicrosoft PlayReady
  2. Google WidevineGoogle Widevine
  3. Apple FairPlayApple FairPlay

La tabella seguente riepiloga l'app nativa/piattaforma e i browser supportati da ogni DRM.The following table summarizes the native platform/native app, and browsers supported by each DRM.

Piattaforma clientClient Platform Supporto DRM nativoNative DRM Support Browser/AppBrowser/App Formati di streamingStreaming Formats
Smart TV, STB operatore, STB OTTSmart TVs, operator STBs, OTT STBs Principalmente PlayReady e/o Widevine e/o altroPlayReady primarily, and/or Widevine, and/or other Linux, Opera, WebKit, altriLinux, Opera, WebKit, Other Vari formatiVarious formats
Dispositivi Windows 10 (PC Windows, tablet Windows, Windows Phone, Xbox)Windows 10 devices (Windows PC, Windows Tablets, Windows Phone, Xbox) PlayReadyPlayReady MS Edge/IE11/EMEMS Edge/IE11/EME


UWPUWP
DASH (per HLS, PlayReady non è supportato)DASH (For HLS, PlayReady is not supported)

DASH, Smooth Streaming (per HLS, PlayReady non è supportato)DASH, Smooth Streaming (For HLS, PlayReady is not supported)
Dispositivi Android (telefoni, tablet, TV)Android devices (Phone, Tablet, TV) WidevineWidevine Chrome/EMEChrome/EME DASH, HLSDASH,HLS
iOS (iPhone, iPad), client OS X e Apple TViOS (iPhone, iPad), OS X clients and Apple TV FairPlayFairPlay Safari 8+/EMESafari 8+/EME HLSHLS

Considerando lo stato attuale della distribuzione per ogni DRM, un servizio solitamente vuole implementare 2 o 3 DRM per assicurarsi di affrontare tutti i tipi di endpoint nel modo migliore.Considering the current state of deployment for each DRM, a service will typically want to implement 2 or 3 DRMs to make sure you address all the types of endpoints in the best way.

Occorre raggiungere un compromesso tra la complessità della logica del servizio e la complessità sul lato client per ottenere un certo livello di esperienza utente nei vari client.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.

Per eseguire la selezione, tenere presente quanto segue:To make your selection, keep in mind these facts:

  • PlayReady viene implementato in modo nativo in tutti i dispositivi Windows e in alcuni dispositivi Android ed è disponibile tramite SDK software su praticamente qualsiasi piattaforma.PlayReady is natively implemented in every Windows device, on some Android devices, and available through software SDKs on virtually any platform
  • Widevine viene implementato in modo nativo in tutti i dispositivi Android, in Chrome e in alcuni altri dispositivi.Widevine is natively implemented in every Android device, in Chrome, and in some other devices
  • FairPlay è disponibile solo in iOS e nei client Mac OS o tramite iTunes.FairPlay is available only on iOS and Mac OS clients or through iTunes.

Quindi, un DRM multiplo tipico corrisponde ai seguenti:So a typical multi-DRM would be:

  • Opzione 1: PlayReady e WidevineOption 1: PlayReady and Widevine
  • Opzione 2: PlayReady, Widevine e FairPlayOption 2: PlayReady, Widevine and FairPlay

Progettazione di riferimentoA reference design

In questa sezione verrà presentata una progettazione di riferimento indipendente dalle tecnologie usate per implementarla.In this section, we will present a reference design which is agnostic to technologies used to implement it.

Un sottosistema DRM può contenere i componenti seguenti:A DRM subsystem may contain the following components:

  1. Gestione della chiaveKey management
  2. Creazione pacchetto DRMDRM packaging
  3. Distribuzione di licenze DRMDRM license delivery
  4. Controllo dei dirittiEntitlement check
  5. Autenticazione/autorizzazioneAuthentication/authorization
  6. LettorePlayer
  7. Origine/rete CDNOrigin/CDN

Il diagramma seguente illustra l'interazione generale tra i componenti in un sottosistema DRM.The following diagram illustrates the high level interaction among the components in a DRM subsystem.

Sottosistema DRM con CENC

I "livelli" di base della progettazione sono tre:There are three basic “layers” in the design:

  1. Livello back office (in nero) non esposto esternamente.Back office layer (in black) which are not exposed externally;
  2. Livello "rete perimetrale" (blu) contenente tutti gli endpoint pubblici.“DMZ” layer (blue) containing all the endpoints facing public;
  3. Livello Internet pubblico (azzurro) contenente la rete CDN e i lettori con traffico su Internet pubblico.Public Internet layer (light blue) containing CDN and players with traffic across public Internet.

Deve essere presente uno strumento di gestione del contenuto per controllare la protezione DRM, indipendentemente dal fatto che si tratti di crittografia statica o dinamica.There should be a content management tool for controlling DRM protection, regardless it is static or dynamic encryption. Gli input per la crittografia DRM devono includere:The inputs for DRM encryption should include:

  1. Contenuto video con velocità in bit multipla.MBR video content;
  2. Chiave simmetrica.Content key;
  3. URL di acquisizione delle licenze.License acquisition URLs.

Durante la fase di riproduzione, il flusso generale è:During playback time, the high level flow is:

  1. L'utente viene autenticato.User is authenticated;
  2. Viene creato il token di autorizzazione per l'utente.Authorization token is created for the user;
  3. Il contenuto protetto da DRM (manifesto) viene scaricato nel lettore.DRM protected content (manifest) is downloaded to player;
  4. Il lettore invia la richiesta di acquisizione di licenza ai server licenze con l'ID chiave e il token di autorizzazione.Player submits license acquisition request to license servers together with key ID and authorization token.

Prima di passare all'argomento successivo, verrà brevemente illustrata la progettazione della gestione delle chiavi.Before moving to the next topic, a few words about the design of key management.

Chiave simmetrica-ad-assetContentKey–to-Asset ScenarioScenario
1-a-11–to-1 È il caso più semplice.The simplest case. Consente il controllo più dettagliato,It provides the finest control. ma in genere comporta il costo maggiore di distribuzione delle licenze.But this generally results in the highest license delivery cost. È necessaria almeno una richiesta di licenza per ogni asset protetto.At minimum one license request is required for each protected asset.
1-a-molti1–to-Many È possibile usare la stessa chiave simmetrica per più asset.You could use the same content key for multiple assets. Ad esempio, per tutti gli asset di un gruppo logico, come un genere o un subset del genere (o genere film), è possibile usare una singola chiave simmetrica.For example, for all the assets in a logical group such as a genre or subset of genre (or Movie Gene), you could use a single content key.
Molti-a-1Many–to-1 Per ogni asset sono necessarie più chiavi simmetriche.Multiple content keys are needed for each asset.

Ad esempio, se è necessario applicare la protezione CENC dinamica con DRM multiplo per MPEG-DASH e la crittografia AES-128 dinamica per HLS, sono necessarie due chiavi simmetriche distinte, entrambe con il proprio ContentKeyType.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, each with its own ContentKeyType. Per la chiave simmetrica usata per la protezione CENC dinamica è consigliabile usare ContentKeyType.CommonEncryption, mentre per la chiave simmetrica usata per la crittografia AES-128 dinamica è consigliabile usare ContentKeyType.EnvelopeEncryption.(For the content key used for dynamic CENC protection, ContentKeyType.CommonEncryption should be used, while for the content key used for dynamic AES-128 encryption, ContentKeyType.EnvelopeEncryption should be used.)

Un altro esempio è quello della protezione CENC del contenuto DASH dove, in teoria, una chiave simmetrica può essere usata per proteggere il flusso video e un'altra chiave simmetrica per proteggere il flusso audio.Another example, in CENC protection of DASH content, in theory, one content key can be used to protect video stream and another content key to protect audio stream.
Molti-a-moltiMany – to - Many È una combinazione dei due scenari precedenti: per ogni asset multiplo nello stesso "gruppo" di asset viene usato un set di chiavi simmetriche.Combination of the above two scenarios: one set of content keys are used for each of the multiple assets in the same asset “group”.

Un altro fattore importante da considerare è l'uso di licenze persistenti e non persistenti.Another important factor to consider is the use of persistent and non-persistent licenses.

Perché queste considerazioni sono importanti?Why are these considerations important?

Hanno un impatto diretto sul costo della distribuzione delle licenze se si usa il cloud pubblico a questo scopo.They have direct impact to license delivery cost if you use public cloud for license delivery. Si considerino i due seguenti casi di progettazione:Let’s consider the following two different design cases to illustrate:

  1. Sottoscrizione mensile: usare una licenza persistente e il mapping chiave simmetrica-ad-asset 1-a-molti.Monthly subscription: Use persistent license, and 1-to-many content key-to-asset mapping. Ad esempio,E.g. per tutti i film per bambini, viene usata un'unica chiave simmetrica per la crittografia.for all the kids movies, we use a single content key for encryption. In questo caso:In this case:

    N. totale di licenze richieste per tutti i film per bambini/dispositivo = 1Total # licenses requested for all kids movies/device = 1

  2. Sottoscrizione mensile: usare una licenza non persistente e il mapping 1-a-1 tra la chiave simmetrica e l'asset.Monthly subscription: Use non-persistent license, and 1-to-1 mapping between content key and asset. In questo caso:In this case:

    N. totale di licenze richieste per tutti i film per bambini/dispositivo = [n. di film guardati] x [n. di sessioni]Total # licenses requested for all kids movies/device = [# movies watched] x [# sessions]

Come si può notare facilmente, le due diverse progettazioni restituiscono modelli di richiesta di licenza molto diversi da cui deriva il costo della distribuzione delle licenze se il servizio di distribuzione delle licenze viene fornito da un cloud pubblico, ad esempio Servizi multimediali di Azure.As you can easily see, the two different designs result in very different license request patterns hence license delivery cost if license delivery service is provided by a public cloud such as Azure Media Services.

Mapping della progettazione alla tecnologia per l'implementazioneMapping design to technology for implementation

Ora verrà eseguito il mapping della progettazione generica alle tecnologie nella piattaforma Microsoft Azure/Servizi multimediali di Azure, specificando la tecnologia da usare per ogni blocco predefinito.Next, we map our generic design to technologies on Microsoft Azure/Azure Media Services platform, by specifying which technology to use for each building block.

La tabella seguente illustra il mapping:The following table shows the mapping:

Blocco predefinitoBuilding Block TechnologyTechnology
LettorePlayer Azure Media PlayerAzure Media Player
Provider di identità (IdP)Identity Provider (IDP) Azure Active DirectoryAzure Active Directory
Servizio token di sicurezzaSecure Token Service (STS) Azure Active DirectoryAzure Active Directory
Flusso di lavoro protezione DRMDRM Protection Workflow Protezione dinamica di Servizi multimediali di AzureAzure Media Services Dynamic Protection
Distribuzione di licenze DRMDRM License Delivery 1. Distribuzione delle licenze di Servizi multimediali di Azure (PlayReady, Widevine, FairPlay) o1. Azure Media Services License Delivery (PlayReady, Widevine, FairPlay), or
2. Server licenze Axinom,2. Axinom License Server,
3. Server licenze PlayReady personalizzato3. Custom PlayReady License Server
OrigineOrigin Endpoint di streaming di Servizi multimediali di AzureAzure Media Services Streaming Endpoint
Gestione della chiaveKey Management Non necessaria per l'implementazione di riferimentoNot needed for reference implementation
Gestione del contenutoContent Management Applicazione console in C#A C# console application

In altre parole, sia il provider di identità (IdP) che il servizio token di sicurezza saranno Azure AD.In other words, both Identity Provider (IDP) and Secure Token Service (STS) will be Azure AD. Come lettore si userà l' API di Azure Media Player.For player, we will use Azure Media Player API. Sia Servizi multimediali di Azure che Azure Media Player supportano DASH e CENC con DRM multiplo.Both Azure Media Services and Azure Media Player support DASH and CENC with multi-DRM.

Il diagramma seguente illustra la struttura e il flusso generali con il mapping alla tecnologia precedente.The following diagram shows the overall structure and flow with the above technology mapping.

CENC in AMS

Per configurare la crittografia CENC dinamica, lo strumento di gestione del contenuto userà gli input seguenti:In order to set up dynamic CENC encryption, the content management tool will use the following inputs:

  1. Contenuto aperto.Open content;
  2. Chiave simmetrica dalla generazione/gestione delle chiavi.Content key from key generation/management;
  3. URL di acquisizione delle licenze.License acquisition URLs;
  4. Un elenco di informazioni da Azure AD.A list of information from Azure AD.

L'output dello strumento di gestione del contenuto sarà:The output of the content management tool will be:

  1. ContentKeyAuthorizationPolicy contenente la specifica relativa alla verifica di un token JWT da parte della distribuzione delle licenze e le specifiche relative alle licenze DRM.ContentKeyAuthorizationPolicy containing the specification on how license delivery verifies a JWT token and DRM license specifications;
  2. AssetDeliveryPolicy contenente le specifiche sul formato di streaming, sulla protezione DRM e sugli URL di acquisizione delle licenze.AssetDeliveryPolicy containing specifications on streaming format, DRM protection and license acquisition URLs.

Durante la fase di esecuzione, il flusso è il seguente:During runtime, the flow is as below:

  1. Durante l'autenticazione utente, viene generato un token JWT.Upon user authentication, a JWT token is generated;
  2. Una delle attestazioni contenuta nel token JWT è l'attestazione "groups" contenente l'ID oggetto gruppo di "EntitledUserGroup".One of the claims contained in the JWT token is “groups” claim containing the group object ID of “EntitledUserGroup”. Questa attestazione verrà usata per superare il controllo "entitlement check".This claim will be used for passing “entitlement check”.
  3. Il lettore scarica il manifesto client di un contenuto protetto da CENC e "vede" quanto segue:Player downloads client manifest of a CENC protected content and “sees” the following:

    1. ID chiave.key ID,
    2. Il contenuto è protetto da CENC.the content is CENC protected,
    3. URL di acquisizione delle licenze.License acquisition URLs.
  4. Il lettore crea una richiesta di acquisizione della licenza basata sul browser/DRM supportato.Player makes a license acquisition request based on the browser/DRM supported. Nella richiesta di acquisizione della licenza verranno inviati anche l'ID chiave e il token JWT.In the license acquisition request, key ID and the JWT token will also be submitted. Il servizio di distribuzione delle licenze verificherà il token JWT e le attestazioni contenute prima di rilasciare la licenza necessaria.License delivery service will verify the JWT token and the claims contained before issuing the needed license.

ImplementazioneImplementation

Procedure di implementazioneImplementation procedures

L'implementazione includerà i passaggi seguenti:The implementation will include the following steps:

  1. Preparare uno o più asset di test: codificare/creare un pacchetto per un video di test in un MP4 frammentato a più velocità in bit in Servizi multimediali di Azure.Prepare test asset(s): encode/package a test video to multi-bitrate fragmented MP4 in Azure Media Services. Questo asset NON è protetto da DRM.This asset is NOT DRM protected. La protezione DRM verrà applicata più avanti con la protezione dinamica.DRM protection will be done by dynamic protection later.
  2. Creare l'ID chiave e la chiave simmetrica (facoltativamente dal seme chiave).Create key ID and content key (optionally from key seed). In questo caso, non è necessario un sistema di gestione delle chiavi perché viene usato un solo set di ID chiave e chiave simmetrica per un paio di asset di test.For our purpose, key management system is not needed since we are dealing with only a single set of key ID and content key for a couple of test assets;
  3. Usare l'API AMS per configurare i servizi di distribuzione delle licenze con DRM multiplo per l'asset di test.Use AMS API to configure multi-DRM license delivery services for the test asset. Se si usano server licenze personalizzati della società o dei fornitori della società invece dei servizi di licenza in Servizi multimediali di Azure, è possibile saltare questo passaggio e specificare gli URL di acquisizione delle licenze nel passaggio relativo alla configurazione della distribuzione delle licenze.If you are using custom license servers by your company or your company’s vendors instead of license services in Azure Media Services, you can skip this step and specify license acquisition URLs in the step for configuring license delivery. L'API AMS è necessaria per specificare alcune configurazioni dettagliate, ad esempio la restrizione dei criteri di autorizzazione, i modelli di risposta di licenza per servizi di licenza DRM diversi e così via. Attualmente il portale di Azure non fornisce ancora l'interfaccia utente necessaria per questa configurazione.AMS API is needed to specify some detailed configurations, such as authorization policy restriction, license response templates for different DRM license services, etc. At this time, the Azure portal does not yet provide the needed UI for this configuration. Le info relative all'API e il codice di esempio sono disponibili nell'articolo seguente: Uso della crittografia comune dinamica PlayReady e/o Widevine.You can find API level info and sample code in the following article: Using PlayReady and/or Widevine Dynamic Common Encryption.
  4. Usare l'API AMS per configurare i criteri di distribuzione per l'asset di test.Use AMS API to configure asset delivery policy for the test asset. Le info relative all'API e il codice di esempio sono disponibili nell'articolo seguente: Uso della crittografia comune dinamica PlayReady e/o Widevine.You can find API level info and sample code in the following article: Using PlayReady and/or Widevine Dynamic Common Encryption.
  5. Creare e configurare un tenant di Azure Active Directory in Azure.Create and configure an Azure Active Directory tenant in Azure;
  6. Creare alcuni account utente e gruppi nel tenant di Azure Active Directory: è consigliabile creare almeno un gruppo "EntitledUser" e aggiungere un utente a questo gruppo.Create a few user accounts and groups in your Azure Active Directory tenant: you should create at least “EntitledUser” group and add a user to this group. Gli utenti di questo gruppo supereranno il controllo dei diritti durante l'acquisizione della licenza, mentre gli utenti non appartenenti a questo gruppo non riusciranno a superare il controllo di autenticazione e non potranno acquisire alcuna licenza.Users in this group will pass entitlement check in license acquisition and users not in this group will fail to pass authentication check and will not be able to acquire any license. Essere membro di questo gruppo "EntitledUser" è un'attestazione "groups" obbligatoria nel token JWT rilasciato da Azure AD.Being a member of this “EntitledUser” group is a required “groups” claim in the JWT token issued by Azure AD. Questo requisito di attestazione deve essere specificato nel passaggio relativo alla configurazione dei servizi di distribuzione di licenze con DRM multiplo.This claim requirement should be specified in configuring multi-DRM license delivery services step.
  7. Creare un'app MVC ASP.NET che ospiterà il lettore video.Create an ASP.NET MVC app which will be hosting your video player. Questa app ASP.NET verrà protetta con l'autenticazione utente nel tenant di Azure Active Directory.This ASP.NET app will be protected with user authentication against the Azure Active Directory tenant. Le attestazioni appropriate verranno incluse nei token di accesso ottenuti dopo l'autenticazione utente.Proper claims will be included in the access tokens obtained after user authentication. Per questo passaggio, è consigliata l'API OpenID Connect.OpenID Connect API is recommended for this step. È necessario installare i pacchetti NuGet seguenti:You need to 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. Creare un lettore usando l' API di Azure Media Player.Create a player using Azure Media Player API. API ProtectionInfo di Azure Media Player consente di specificare la tecnologia DRM da usare in una piattaforma DRM diversa.Azure Media Player’s ProtectionInfo API allows you to specify which DRM technology to use on different DRM platform.
  9. Testare la matrice:Test matrix:
DRMDRM BrowserBrowser Risultato per un utente idoneoResult for Entitled User Risultato per un utente non idoneoResult for Un-entitled User
PlayReadyPlayReady MS Edge o IE11 in Windows 10MS Edge or IE11 on Windows 10 SucceedSucceed FailFail
WidevineWidevine Chrome in Windows 10Chrome on Windows 10 SucceedSucceed FailFail
FairPlayFairPlay Da definireTBD

George Trifonov del team di Servizi multimediali di Azure ha scritto un blog con i passaggi dettagliati per configurare Azure Active Directory per un'app lettore ASP.NET MVC: Integrare l'app basata su OWIN MVC di Servizi multimediali di Azure con Azure Active Directory e limitare la distribuzione di chiavi simmetriche in base ad attestazioni JWT.George Trifonov of Azure Media Services Team has written a blog providing detailed steps in setting up Azure Active Directory for an ASP.NET MVC player app: Integrate Azure Media Services OWIN MVC based app with Azure Active Directory and restrict content key delivery based on JWT claims.

George ha scritto anche un blog relativo all' autenticazione di token JWT in Servizi multimediali di Azure e alla crittografia dinamica.George has also written a blog on JWT token Authentication in Azure Media Services and Dynamic Encryption.

Per informazioni su Azure Active Directory:For information on Azure Active Directory:

Problematiche di implementazioneSome gotchas in implementation

Esistono alcuni "trabocchetti" nell'implementazione.There are some “gotchas” in the implementation. L'elenco seguente di "trabocchetti" dovrebbe essere d'aiuto per risolvere eventuali problemi.Hopefully the following list of “gotchas” can help you troubleshooting in case you run into issues.

  1. L'URL dell'autorità di certificazione deve terminare con "/".Issuer URL should end with "/".

    Audience deve corrispondere all'ID client dell'applicazione lettore ed è anche consigliabile aggiungere "/" alla fine dell'URL dell'autorità di certificazione.Audience should be the player application client ID and you should 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.windows.net/[AAD Tenant ID]/" />
    

    In JWT Decoder verranno visualizzati aud e iss come nel token JWT seguente:In JWT Decoder, you should see aud and iss as below in the JWT token:

    Primo trabocchetto

  2. Aggiungere le autorizzazioni all'applicazione in AAD (nella scheda Configura dell'applicazione).Add Permissions to the application in AAD (on Configure tab of the application). Questa operazione è obbligatoria per ogni applicazione (versioni locali e distribuite).This is required for each application (local and deployed versions).

    Secondo trabocchetto

  3. Usare l'autorità di certificazione corretta durante la configurazione della protezione CENC dinamica:Use the right issuer in setting up dynamic CENC protection:

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

    La seguente non funzionerà:The following will not work:

     <add key="ida:issuer" value="https://willzhanad.onmicrosoft.com/" />
    

    Il GUID è l'ID tenant di AAD.The GUID is the AAD tenant ID. Il GUID è presente nel popup Endpoint nel portale di Azure.The GUID can be found in Endpoints popup in Azure portal.

  4. Concedere i privilegi delle attestazioni di appartenenza al gruppo.Grant group membership claims privileges. Verificare che nel file manifesto dell'applicazione AAD, sia presente quanto segue:Make sure in AAD application manifest file, we have the following

    "groupMembershipClaims": "All" (il valore predefinito è Null)"groupMembershipClaims": "All", (the default value is null)

  5. Impostare l'oggetto TokenType appropriato quando si creano i requisiti relativi alle restrizioni.Setting proper TokenType when creating restriction requirements.

     objTokenRestrictionTemplate.TokenType = TokenType.JWT;
    

    Dopo l'aggiunta del supporto di JWT (AAD) oltre a SWT (ACS), l'oggetto TokenType predefinito è TokenType.JWT.Since adding support of JWT (AAD) in addition to SWT (ACS), the default TokenType is TokenType.JWT. Se si usa SWT/ACS, è necessario impostarlo su TokenType.SWT.If you use SWT/ACS, you must set to TokenType.SWT.

Argomenti aggiuntivi per l'implementazioneAdditional Topics for Implementation

Verranno ora illustrati alcuni argomenti aggiuntivi sulla progettazione e l'implementazione.Next we will disc uss some additional topics in our design and implementation.

HTTP o HTTPS?HTTP or HTTPS?

L'applicazione lettore MVC ASP.NET compilata deve supportare quanto segue:The ASP.NET MVC player application we built must support the following:

  1. Autenticazione utente con Azure AD, che deve usare HTTPS.User authentication through Azure AD which needs to be under HTTPS;
  2. Scambio di token JWT tra il client e Azure AD, che deve usare HTTPS.JWT token exchange between client and Azure AD which needs to be under HTTPS;
  3. Acquisizione della licenza DRM dal client, che deve essere gestita tramite HTTPS se la distribuzione delle licenze avviene tramite Servizi multimediali di Azure.DRM license acquisition by the client which is required to be under HTTPS if license delivery is provided by Azure Media Services. Naturalmente, la famiglia di prodotti PlayReady non obbliga a usare HTTPS per la distribuzione delle licenze.Of course, PlayReady product suite does not mandate HTTPS for license delivery. Se il server delle licenze PlayReady non rientra nei Servizi multimediali di Azure, usare HTTP o HTTPS.If your PlayReady license server is outside of Azure Media Services, either HTTP or HTTPS could be used.

L'applicazione lettore ASP.NET dovrà quindi usare HTTPS come procedura consigliata.Therefore, the ASP.NET player application will use HTTPS as a best practice. Ciò significa che Azure Media Player sarà in una pagina con HTTPS.This means the Azure Media Player will be on a page under HTTPS. Tuttavia, per lo streaming è preferibile HTTP, perciò è necessario considerare il problema del contenuto misto.However, for streaming we prefer HTTP, hence we need to consider mixed content issue.

  1. Il browser non consente il contenuto misto,Browser does not allow mixed content. ma lo consentono i plug-in come Silverlight e il plug-in OSMF per Smooth e DASH.But plugins like Silverlight and OSMF plugin for smooth and DASH allow. Il contenuto misto pone una questione di sicurezza a causa della minaccia derivante dalla possibilità di inserire codice JS dannoso che può mettere a rischio i dati dei clienti.Mixed content is a security concern - This is due to the threat of the ability to inject malicious JS which can cause the customer data to be at risk. I browser lo bloccano per impostazione predefinita e finora il solo modo per aggirare il problema è intervenire sul lato server (origine), per consentire tutti i domini (sia https che http),Browsers block this by default and so far the only way to work around it is on the server (origin) side, to allow all domains (regardless https or http). ma probabilmente nemmeno questa è una buona idea.This is probably not a good idea either.
  2. È consigliabile evitare il contenuto misto: entrambi devono usare HTTP o HTTPS.We should avoid mixed content: either both use HTTP or both use HTTPS. Quando gestisce il contenuto misto, la tecnologia silverlightSS richiede la cancellazione di un avviso di contenuto misto.When playing mixed content, silverlightSS tech requires clearing a mixed content warning. La tecnologia flashSS gestisce il contenuto misto senza avvisi di contenuto misto.flashSS tech handles mixed content without mixed content warning.
  3. Se l'endpoint di streaming è stato creato prima di agosto 2014, non supporterà HTTPS.If your streaming endpoint was created before August 2014, it will not support HTTPS. In questo caso, creare e usare un nuovo endpoint di streaming per HTTPS.In this case, please create and use a new streaming endpoint for HTTPS.

Nell'implementazione di riferimento, per i contenuti protetti da DRM, sia l'applicazione che il flusso useranno HTTTPS.In the reference implementation, for DRM protected contents, both application and streaming will be under HTTTPS. Per i contenuti aperti, per il lettore non è necessaria l'autenticazione o la licenza, quindi è possibile usare HTTP o HTTPS.For open contents, the player does not need authentication or license, so you have the liberty to use either HTTP or HTTPS.

Rollover della chiave per la firma di Azure Active DirectoryAzure Active Directory signing key rollover

Questo è un aspetto importante da considerare per l'implementazione.This is an important point to take into consideration of your implementation. In caso contrario, il sistema completato smetterà di funzionare completamente entro 6 settimane al massimo.If you do not consider this in your implementation, the completed system will eventually stop working completely within at most 6 weeks.

Azure AD usa lo standard di settore per stabilire una relazione di trust tra se stesso e le applicazioni che usano Azure AD.Azure AD uses industry standard to establish trust between itself and applications using Azure AD. In particolare, Azure AD usa una chiave per la firma costituita da una coppia di chiavi pubblica e privata.Specifically, Azure AD uses a signing key that consists of a public and private key pair. Quando Azure AD crea un token di sicurezza contenente informazioni sull'utente, questo token viene firmato da Azure AD con la chiave privata prima che venga inviato di nuovo all'applicazione.When Azure AD creates a security token that contains information about the user, this token is signed by Azure AD using its private key before it is sent back to the application. Per verificare che il token sia valido e sia stato realmente originato da Azure AD, l'applicazione deve convalidare la firma del token usando la chiave pubblica esposta da Azure AD contenuta nel documento di metadati federativi del tenant.To verify that the token is valid and actually originated from Azure AD, the application must validate the token’s signature using the public key exposed by Azure AD that is contained in the tenant’s federation metadata document. Questa chiave pubblica e la chiave per la firma da cui deriva sono le stesse usate per tutti i tenant in Azure AD.This public key – and the signing key from which it derives – is the same one used for all tenants in Azure AD.

Informazioni dettagliate sul rollover della chiave di Azure AD sono disponibili nel documento: Important Information about Signing Key Rollover in Azure AD(Informazioni importanti sul rollover della chiave di firma in Azure AD).Detailed info on Azure AD key rollover can be found in the document: Important Information about Signing Key Rollover in Azure AD.

Tra la coppia di chiavi pubblica-privata:Between the public-private key pair,

  • La chiave privata viene usata da Azure Active Directory per generare un token JWT.The private key is used by Azure Active Directory to generate a JWT token;
  • La chiave pubblica viene usata da un'applicazione, ad esempio i servizi di distribuzione delle licenze DRM in AMS, per verificare il token JWT.The public key is used by an application such as DRM License Delivery Services in AMS to verify the JWT token;

Per motivi di sicurezza, Azure Active Directory fa girare questo certificato periodicamente (ogni 6 settimane).For security purpose, Azure Active Directory rotates this certificate periodically (every 6 weeks). In caso di violazioni della sicurezza, il rollover della chiave può essere eseguito in qualsiasi momento.In case of security breaches, the key rollover can occur any time. Quindi i servizi di distribuzione delle licenze in AMS devono aggiornare la chiave pubblica usata quando Azure AD fa ruotare la coppia di chiavi. In caso contrario, l'autenticazione token in AMS non riuscirà e non verrà rilasciata alcuna licenza.Therefore, the license delivery services in AMS need to update the public key used as Azure AD rotates the key pair, otherwise token authentication in AMS will fail and no license will be issued.

Questo risultato viene ottenuto impostando TokenRestrictionTemplate.OpenIdConnectDiscoveryDocument quando si configurano i servizi di distribuzione delle licenze DRM.This is achieved by setting TokenRestrictionTemplate.OpenIdConnectDiscoveryDocument when configuring DRM license delivery services.

Il flusso del token JWT è il seguente:The JWT token flow is as below:

  1. Azure AD rilascerà il token JWT con la chiave privata corrente per un utente autenticato.Azure AD will issue the JWT token with the current private key for an authenticated user;
  2. Quando un lettore visualizza un contenuto protetto da CENC con DRM multiplo, individuerà prima il token JWT rilasciato da Azure AD.When a player sees a CENC with multi-DRM protected content, it will first locate the JWT token issued by Azure AD.
  3. Il lettore invia la richiesta di acquisizione della licenza con il token JWT ai servizi di distribuzione delle licenze in AMS.The player sends license acquisition request with the JWT token to license delivery services in AMS;
  4. I servizi di distribuzione delle licenze in AMS useranno la chiave pubblica corrente/valida di Azure AD per verificare il token JWT, prima di rilasciare le licenze.The license delivery services in AMS will use the current/valid public key from Azure AD to verify the JWT token, before issuing licenses.

I servizi di distribuzione delle licenze DRM cercheranno sempre la chiave pubblica corrente/valida di Azure AD.DRM license delivery services will always be checking for the current/valid public key from Azure AD. La chiave pubblica presentata da Azure AD sarà la chiave usata per verificare un token JWT rilasciato da Azure AD.The public key presented by Azure AD will be the key used for verifying a JWT token issued by Azure AD.

Che cosa accade se il rollover della chiave viene eseguito dopo che AAD ha generato un token JWT, ma prima che il token JWT venga inviato dai lettori ai servizi di distribuzione delle licenze DRM in AMS per la verifica?What if the key rollover happens after AAD generates a JWT token but before the JWT token is sent by players to DRM license delivery services in AMS for verification?

Poiché il rollover di una chiave può essere eseguito in qualsiasi momento, nel documento di metadati federativi è sempre disponibile più di una chiave pubblica valida.Because a key may be rolled at any moment, there is always more than one valid public key available in the federation metadata document. La distribuzione delle licenze di Servizi multimediali di Azure può usare qualsiasi chiave specificata nel documento, perché di una chiave può essere eseguito il rollover a breve, un'altra può essere quella sostitutiva e così via.Azure Media Services license delivery can use any of the keys specified in the document, since one key may be rolled soon, another may be its replacement, and so forth.

Dov'è il token di accesso?Where is the Access Token?

Se si esamina come un'app Web chiama un'app per le API in Identità applicazione con concessione delle credenziali client OAuth 2.0, il flusso di autenticazione è il seguente: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 below:

  1. Un utente esegue l'accesso ad Azure AD nell'applicazione Web (vedere Da Web browser ad applicazione Web).A user is signed in to Azure AD in the web application (see the Web Browser to Web Application.
  2. L'endpoint di autorizzazione di Azure AD reindirizza di nuovo l'agente utente all'applicazione client con un codice di autorizzazione.The Azure AD authorization endpoint redirects the user agent back to the client application with an authorization code. L'agente utente restituisce il codice di autorizzazione all'URI di reindirizzamento dell'applicazione client.The user agent returns authorization code to the client application’s redirect URI.
  3. L'applicazione Web deve acquisire un token di accesso per l'autenticazione nell'API Web e il recupero della risorsa desiderata.The web application needs to acquire an access token so that it can authenticate to the web API and retrieve the desired resource. Esegue una richiesta all'endpoint token di Azure AD, fornendo credenziali, ID client e URI ID applicazione dell'API Web.It makes a request to Azure AD’s token endpoint, providing the credential, client ID, and web API’s application ID URI. Presenta il codice di autorizzazione per dimostrare che l'utente ha acconsentito.It presents the authorization code to prove that the user has consented.
  4. Azure AD autentica l'applicazione e restituisce un token di accesso JWT usato per chiamare l'API Web.Azure AD authenticates the application and returns a JWT access token that is used to call the web API.
  5. Su HTTPS l'applicazione Web usa il token di accesso JWT restituito per aggiungere la stringa JWT con una designazione "Bearer" nell'intestazione dell'autorizzazione della richiesta all'API Web.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. L'API Web convalida quindi il token JWT e, se la convalida riesce, restituisce la risorsa desiderata.The web API then validates the JWT token, and if validation is successful, returns the desired resource.

In questo flusso di "identità dell'applicazione" l'API Web confida che l'applicazione Web abbia autenticato l'utente.In this “application identity” flow, the web API trusts that the web application authenticated the user. Per questo motivo il modello è definito sottosistema attendibile.For this reason, this pattern is called a trusted subsystem. Il diagramma in questa pagina illustra come il codice di autorizzazione garantisca il funzionamento del flusso.The diagram on this page describes how authorization code grant flow works.

Nell'acquisizione della licenza con la restrizione token si sta seguendo lo stesso modello di sottosistema attendibile.In license acquisition with token restriction, we are following the same trusted subsystem pattern. E il servizio di distribuzione delle licenze in Servizi multimediali di Azure è la risorsa API Web, ovvero la "risorsa back-end" a cui un'applicazione Web deve accedere.And the license delivery service in Azure Media Services is the web API resource, the “backend resource” a web application needs to access. Dov'è quindi il token di accesso?So where is the access token?

In realtà il token di accesso viene ottenuto da Azure AD.Indeed, we are obtaining access token from Azure AD. Al termine dell'autenticazione utente, viene restituito il codice di autorizzazione.After successful user authentication, authorization code is returned. Il codice di autorizzazione viene quindi usato, con l'ID client e la chiave app, per ottenere in cambio il token di accesso.The authorization code is then used, together with client ID and app key, to exchange for access token. Il token di accesso serve per accedere a un'applicazione "puntatore" che punta a un servizio di distribuzione delle licenze di Servizi multimediali di Azure o lo rappresenta.And the access token is for accessing a “pointer” application pointing or representing Azure Media Services license delivery service.

È necessario registrare e configurare l'app "puntatore" in Azure AD seguendo questa procedura:We need to register and configure the “pointer” app in Azure AD by following the steps below:

  1. Nel tenant di Azure ADIn the Azure AD tenant

    • aggiungere un'applicazione (risorsa) con l'URL di accesso:add an application (resource) with sign-on URL:

    https://[nome_risorsa].azurewebsites.net/ ehttps://[resource_name].azurewebsites.net/ and

    • l'URL dell'ID app:app ID URL:

    https://[nome_tenant_aad].onmicrosoft.com/[nome_risorsa];https://[aad_tenant_name].onmicrosoft.com/[resource_name];

  2. Aggiungere una nuova chiave per l'app risorsa.Add a new key for the resource app;
  3. Aggiornare il file manifesto dell'app in modo che il valore della proprietà groupMembershipClaims sia il seguente: "groupMembershipClaims": "All".Update the app manifest file so that the groupMembershipClaims property has the following value: "groupMembershipClaims": "All",
  4. Nell'app Azure AD che punta all'app Web del lettore, nella sezione "Autorizzazioni per altre applicazioni" aggiungere l'app risorsa aggiunta nel passaggio 1.In the Azure AD app pointing to the player web app, in the section “permissions to other applications”, add the resource app that was added in step 1 above. In "Autorizzazioni delegate" selezionare la casella di controllo "Accedi a [nome_risorsa]".Under “delegated permissions” check “Access [resource_name]” checkmark. L'app Web avrà così l'autorizzazione per creare i token di accesso per accedere all'app risorsa.This gives the web app permission to create access tokens for accessing the resource app. È consigliabile eseguire questa operazione sia per la versione locale che per quella distribuita dell'app Web se si sviluppa con Visual Studio e l'app Web di Azure.You should do this for both local and deployed version of the web app if you are developing with Visual Studio and Azure web app.

Quindi il token JWT rilasciato da Azure AD è in realtà il token di accesso per accedere a questa risorsa "puntatore".Therefore, the JWT token issued by Azure AD is indeed the access token for accessing this “pointer” resource.

Come funziona lo streaming live?What about Live Streaming?

Nella parte precedente la discussione si è concentrata sugli asset su richiesta.In the above, our discussion has been focusing on on-demand assets. Come funziona lo streaming live?What about live streaming?

L'aspetto positivo è che è possibile usare esattamente la stessa progettazione e la stessa implementazione per proteggere lo streaming live in Servizi multimediali di Azure, trattando l'asset associato a un programma come "asset VOD".The good news is that you can use exactly the same design and implementation for protecting live streaming in Azure Media Services, by treating the asset associated with a program as a “VOD asset.”

In particolare, è risaputo che, per eseguire lo streaming live in Servizi multimediali di Azure, è necessario creare un canale, quindi un programma nel canale.Specifically, it is well known that to do live streaming in Azure Media Services, you need to create a channel, then a program under the channel. Per creare il programma, è necessario creare un asset che conterrà l'archivio live per il programma.To create the program, you need to create an asset that will contain the live archive for the program. Per fornire la protezione CENC con DRM multiplo del contenuto live, è sufficiente applicare all'asset la stessa configurazione/elaborazione che si applicherebbe se fosse un "asset VOD" prima di avviare il programma.In order to provide CENC with multi-DRM protection of the live content, all you need to do, is to apply the same setup/processing to the asset as if it was a “VOD asset” before you start the program.

Come funzionano i server licenze al di fuori di Servizi multimediali di Azure?What about license servers outside of Azure Media Services?

I clienti spesso investono in una farm di server licenze nel proprio data center o ospitata da provider di servizi DRM.Often, customers may have invested in license server farm either in their own data center or hosted by DRM service providers. Fortunatamente, la protezione del contenuto di Servizi multimediali di Azure consente di operare in modalità ibrida: i contenuti sono ospitati e protetti in modo dinamico in Servizi multimediali di Azure, mentre le licenze DRM vengono distribuite da server al di fuori di Servizi multimediali di Azure.Fortunately, Azure Media Services Content Protection allows you to operate in hybrid mode: contents hosted and dynamically protected in Azure Media Services, while DRM licenses are delivered by servers outside Azure Media Services. In questo caso, considerare le modifiche seguenti:In this case, there are the following considerations of changes:

  1. Secure Token Service deve rilasciare token che siano accettabili e verificabili dalla farm di server licenze.The Secure Token Service needs to issue tokens that are acceptable and can be verified by the license server farm. Ad esempio, il server licenze Widevine fornito da Axinom richiede uno specifico token JWT contenente un elemento "entitlement message".For example, the Widevine license servers provided by Axinom require a specific JWT token that contains “entitlement message.” Per rilasciare tale token JWT, è quindi necessario un servizio token di sicurezza.Therefore, you need to have an STS to issue such JWT token. Gli autori hanno completato questa implementazione, i cui dettagli sono disponibili nel documento seguente del Centro di documentazione di Azure: Uso di Axinom per fornire licenze Widevine ai Servizi multimediali di Azure.The authors have completed such an implementation and you can find the details in the following document in Azure Documentation Center: Using Axinom to deliver Widevine licenses to Azure Media Services.
  2. Non è più necessario configurare il servizio di distribuzione delle licenze (ContentKeyAuthorizationPolicy) in Servizi multimediali di Azure.You no longer need to configure license delivery service (ContentKeyAuthorizationPolicy) in Azure Media Services. È sufficiente fornire gli URL di acquisizione delle licenze (per PlayReady, Widevine e FairPlay) quando si configura AssetDeliveryPolicy durante la configurazione di CENC con DRM multiplo.What you need to do is to provide the license acquisition URLs (for PlayReady, Widevine and FairPlay) when you configure AssetDeliveryPolicy in setting up CENC with multi-DRM.

Come procedere per usare un servizio token di sicurezza personalizzato?What if I want to use a custom STS?

Un cliente può scegliere di usare un servizio token di sicurezza personalizzato per fornire i token JWT per diversi morivi.There could be a few reasons that a customer may choose to use a custom STS (Secure Token Service) for providing JWT tokens. Eccone alcuni:Some of them are:

  1. Il provider di identità (IdP) usato dal cliente non supporta il servizio token di sicurezza.The Identity Provider (IDP) used by the customer does not support STS. In questo caso un servizio token di sicurezza personalizzato può essere una soluzione.In this case, a custom STS may be an option.
  2. Il cliente può avere bisogno di un controllo più flessibile o più rigido nell'integrazione del servizio token di sicurezza con il sistema di fatturazione sottoscrittore del cliente.The customer may need more flexible or tighter control in integrating STS with customer’s subscriber billing system. Un operatore MVPD, ad esempio, può offrire più pacchetti sottoscrittore OTT, ad esempio Premium, Basic, Sport e così via. L'operatore può associare le attestazioni in un token al pacchetto di un sottoscrittore in modo che siano disponibili solo i contenuti del pacchetto corretto.For example, an MVPD operator may offer multiple OTT subscriber packages such as premium, basic, sports, etc. The operator may want to match the claims in a token with a subscriber’s package so that only contents in the right package is made available. In questo caso, un servizio token di sicurezza personalizzato fornisce la flessibilità e il controllo necessari.In this case, a custom STS provides the needed flexibility and control.

Quando si usa un servizio token di sicurezza personalizzato, è necessario apportare due modifiche:Two changes need to be made when using a custom STS:

  1. Quando si configura un servizio di distribuzione delle licenze per un asset, è necessario specificare la chiave di sicurezza usata per la verifica dal servizio token di sicurezza personalizzato (per altri dettagli, vedere di seguito) invece della chiave corrente di Azure Active Directory.When configuring license delivery service for an asset, you need to specify the security key used for verification by the custom STS (more details below) instead of the current key from Azure Active Directory.
  2. Quando viene generato un token JTW, viene specificata una chiave di sicurezza invece della chiave privata del certificato X509 corrente in Azure Active Directory.When a JTW token is generated, a security key is specified instead of the private key of the current X509 certificate in Azure Active Directory.

Esistono due tipi di chiavi di sicurezza:There are two types of security keys:

  1. Chiave simmetrica: la stessa chiave viene usata sia per la generazione che per la verifica di un token JWT.Symmetric key: the same key is used for both generating and verifying a JWT token;
  2. Chiave asimmetrica: un coppia di chiavi pubblica-privata in un certificato X509 viene usata con la chiave privata per la crittografia/generazione di un token JWT e con la chiave pubblica per la verifica del token.Asymmetric key: a public-private key pair in an X509 certificate is used with private key for encrypting/generating a JWT token and the public key for verifying the token.

Nota tecnicaTech note

Se si usa .NET Framework/C# come piattaforma di sviluppo, il certificato X509 usato per la chiave di sicurezza asimmetrica deve avere una lunghezza della chiave pari almeno a 2048 bit.If you use .NET Framework/C# as your development platform, the X509 certificate used for asymmetric security key must have key length at least 2048. È un requisito della classe System.IdentityModel.Tokens.X509AsymmetricSecurityKey in .NET Framework.This is a requirement of the class System.IdentityModel.Tokens.X509AsymmetricSecurityKey in .NET Framework. In caso contrario, verrà generata un'eccezione simile alla seguente:Otherwise, the following exception will be thrown:

IDX10630: 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey' per la firma non può essere inferiore a '2048' bit.IDX10630: The 'System.IdentityModel.Tokens.X509AsymmetricSecurityKey' for signing cannot be smaller than '2048' bits.

Sistema completato e testThe completed system and test

Vengono illustrati alcuni scenari nel sistema end-to-end completato per offrire ai lettori una panoramica generale del comportamento prima che ottengano un account di accesso.We walk through a few scenarios in the completed end-to-end system so that readers can have a basic “picture” of the behavior before getting a login account.

L'applicazione Web del lettore e l'account di accesso sono disponibili qui.The player web application and its login can be found here.

Se è necessario uno scenario "non integrato" in cui gli asset video sono ospitati in Servizi multimediali di Azure non protetti o protetti da DRM, ma senza autenticazione token (viene rilasciata una licenza a chiunque la richieda), è possibile testarlo senza accedere (passando a HTTP se il flusso video è su HTTP).If what you need is “non-integrated” scenario: video assets hosted in Azure Media Services that are either unprotected, or DRM protected but without token authentication (issuing a license to whoever requesting it), you can test it without login (by switching to HTTP if your video streaming is over HTTP).

Se è necessario uno scenario end-to-end integrato in cui gli asset video usano la protezione DRM dinamica in Servizi multimediali di Azure, con l'autenticazione token e il token JWT generato da Azure AD, è necessario effettuare l'accesso.If what you need is end-to-end integrated scenario: video assets is under dynamic DRM protection in Azure Media Services, with token authentication and JWT token being generated by Azure AD, you need to log in.

Accesso utenteUser login

Per testare il sistema DRM end-to-end integrato, è necessario che sia stato creato o aggiunto un "account".In order to test the end-to-end integrated DRM system, you need to have an “account” created or added.

Quale account?What account?

Anche se in origine l'accesso ad Azure era consentito solo agli utenti con account Microsoft, ora è invece consentito l'accesso agli utenti di entrambi i sistemi.Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. A questo scopo, tutte le proprietà di Azure devono considerare Azure AD come attendibile per l'autenticazione, Azure AD deve autenticare gli utenti aziendali e creare una relazione federativa in cui Azure AD considera attendibile il sistema di identità utente degli account Microsoft per autenticare gli utenti privati.This was done by having all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. Di conseguenza, Azure AD è ora in grado di autenticare gli account Microsoft "guest" e gli account Azure AD "nativi".As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.

Poiché Azure AD considera attendibile il dominio account Microsoft (MSA), è possibile aggiungere qualsiasi account da uno dei domini seguenti al tenant di Azure AD personalizzato e usare l'account per l'accesso:Since Azure AD trusts Microsoft Account (MSA) domain, you can add any accounts from any of the following domains to the custom Azure AD tenant and use the account to log in:

Nome di dominioDomain Name DominioDomain
Dominio del tenant di Azure AD personalizzatoCustom Azure AD tenant domain nome.onmicrosoft.comsomename.onmicrosoft.com
Dominio aziendaleCorporate domain microsoft.commicrosoft.com
Dominio account Microsoft (MSA)Microsoft Account (MSA) domain outlook.com, live.com, hotmail.comoutlook.com, live.com, hotmail.com

È possibile contattare gli autori per farsi creare o aggiungere un account.You may contact any of the authors to have an account created or added for you.

Di seguito sono riportati gli screenshot di alcune pagine di accesso usate da diversi account dominio.Below are the screenshots of different login pages used by different domain accounts.

Account dominio del tenant di Azure AD personalizzato: in questo caso, viene visualizzata la pagina di accesso personalizzata del dominio del tenant di Azure AD.Custom Azure AD tenant domain account: In this case, you see the customized login page of the custom Azure AD tenant domain.

Account dominio del tenant di Azure AD personalizzato

Account dominio Microsoft con smart card: in questo caso, viene visualizzata la pagina di accesso personalizzata dall'IT aziendale Microsoft con autenticazione a due fattori.Microsoft domain account with smart card: In this case, you see the login page customized by Microsoft corporate IT with two-factor authentication.

Account dominio del tenant di Azure AD personalizzato

Account Microsoft (MSA): in questo caso, viene visualizzata la pagina di accesso dell'account Microsoft per i clienti.Microsoft Account (MSA): In this case, you see the login page of Microsoft Account for consumers.

Account dominio del tenant di Azure AD personalizzato

Uso di Encrypted Media Extensions per PlayReadyUsing Encrypted Media Extensions for PlayReady

In un browser moderno con il supporto EME (Encrypted Media Extensions) per PlayReady, ad esempio IE 11 in Windows 8.1 e versioni successive e il browser Microsoft Edge in Windows 10, PlayReady è il sistema DRM sottostante per EME.On a modern browser with Encrypted Media Extensions (EME) for PlayReady support, such as IE 11 on Windows 8.1 and up, and Microsoft Edge browser on Windows 10, PlayReady is the underlying DRM for EME.

Uso di EME per PlayReady

Nel lettore è presente un'area scura perché la protezione di PlayReady impedisce di acquisire schermate da un video protetto.The dark player area is due to the fact that PlayReady protection prevents one from making screen capture of protected video.

La schermata seguente mostra i plug-in del lettore e il supporto MSE/EME.The following screen shows the player plugins and MSE/EME support.

Uso di EME per PlayReady

EME in Microsoft Edge e IE 11 in Windows 10 consente di chiamare PlayReady SL3000 sui dispositivi Windows 10 che lo supportano.EME in Microsoft Edge and IE 11 on Windows 10 allows invoking of PlayReady SL3000 on Windows 10 devices that support it. PlayReady SL3000 sblocca il flusso di contenuti premium avanzati (4 KB, HDR e così via) e nuovi modelli di distribuzione dei contenuti (finestra anticipata per contenuti avanzati).PlayReady SL3000 unlocks the flow of enhanced premium content (4K, HDR, etc.) and new content delivery models (early window for Enhanced Content).

Concentrarsi sui dispositivi Windows: PlayReady è il solo DRM nell'hardware disponibile nei dispositivi Windows (PlayReady SL3000).Focus on the Windows devices: PlayReady is the only DRM in the HW available on Windows devices (PlayReady SL3000). Un servizio di streaming può usare PlayReady tramite EME o un'applicazione UWP e offrire una migliore qualità video usando PlayReady SL3000 anziché un altro DRM.A streaming service can use PlayReady through EME or through a UWP application and offer a higher video quality using PlayReady SL3000 than another DRM. In genere, i contenuti 2K passano attraverso Chrome o Firefox e i contenuti 4K attraverso Microsoft Edge/IE11 o un'applicazione UWP sullo stesso dispositivo (a seconda delle impostazioni di servizio e dell'implementazione).Typically, 2K content flows through Chrome or Firefox, and 4K content through Microsoft Edge/IE11 or a UWP application on the same device (depending on service settings and implementation).

Uso di EME per WidevineUsing EME for Widevine

In un browser moderno con il supporto EME/Widevine, ad esempio Chrome 41+ in Windows 10, Windows 8.1, Mac OSX Yosemite e Chrome in Android 4.4.4, Google Widevine è il sistema DRM dietro EME.On a modern browser with EME/Widevine support, such as Chrome 41+ on Windows 10, Windows 8.1, Mac OSX Yosemite, and Chrome on Android 4.4.4, Google Widevine is the DRM behind EME.

Uso di EME per Widevine

Si noti che Widevine non impedisce di acquisire schermate da un video protetto.Notice that Widevine does not prevent one from making screen capture of protected video.

Uso di EME per Widevine

Utenti non idoneiNot entitled users

Se un utente non è membro del gruppo di utenti idonei, l'utente non potrà superare il controllo dei diritti e il servizio di licenza con DRM multiplo rifiuterà di rilasciare la licenza richiesta, come illustrato di seguito.If a user is not a member of "Entitled Users" group, the user will not be able to pass “entitlement check” and the multi-DRM license service will refuse to issue the requested license as shown below. La descrizione dettagliata è "License acquire failed", come previsto dalla progettazione.The detailed description is “License acquire failed”, which is as designed.

Utenti non idonei

Esecuzione del servizio token di sicurezza personalizzatoRunning custom Secure Token Service

Per lo scenario dell'esecuzione del servizio token di sicurezza personalizzato, il token JWT viene rilasciato dal servizio token di sicurezza personalizzato usando la chiave simmetrica o asimmetrica.For the scenario of running custom Secure Token Service (STS), the JWT token is issued by the custom STS using either symmetric or asymmetric key.

Uso della chiave simmetrica (con Chrome):The case of using symmetric key (using Chrome):

Esecuzione del servizio token di sicurezza personalizzato

Uso della chiave asimmetrica tramite un certificato X509 (con un browser Microsoft moderno).The case of using asymmetric key via an X509 certificate (using Microsoft modern browser).

Esecuzione del servizio token di sicurezza personalizzato

In entrambi i casi precedenti, l'autenticazione utente è la stessa, ovvero tramite Azure AD.In both of the above cases, user authentication stays the same – through Azure AD. L'unica differenza è che i token JWT vengono rilasciati dal servizio token di sicurezza personalizzato invece che da Azure AD.The only difference is that JWT tokens are issued by the custom STS instead of Azure AD. Quando si configura la protezione CENC dinamica, la restrizione del servizio di distribuzione delle licenze specifica il tipo di token JWT, una chiave simmetrica o asimmetrica.When configuring dynamic CENC protection, the restriction of license delivery service specifies the type of JWT token, either symmetric or asymmetric key.

RiepilogoSummary

In questo documento è stata illustrata la crittografia CENC con DRM nativo multiplo e il controllo di accesso tramite l'autenticazione token: la progettazione e l'implementazione con Azure, Servizi multimediali di Azure e Azure Media Player.In this document, we discussed CENC with multi-native-DRM and access control via token authentication: its design and its implementation using Azure, Azure Media Services, and Azure Media Player.

  • È stata presentata una progettazione di riferimento contenente tutti i componenti necessari nel sottosistema DRM/CENC.A reference design is presented which contains all the necessary components in a DRM/CENC subsystem;
  • Implementazione di riferimento in Azure, Servizi multimediali di Azure e Azure Media Player.A reference implementation on Azure, Azure Media Services, and Azure Media Player.
  • Sono stati illustrati anche alcuni argomenti direttamente collegati alla progettazione e all'implementazione.Some topics directly involved in the design and implementation are also discussed.

Percorsi di apprendimento di Servizi multimedialiMedia Services learning paths

Altre informazioni sui percorsi di apprendimento di Servizi multimediali di Azure:Read about the Azure Media Services learning paths:

Fornire commenti e suggerimentiProvide feedback

Usare il forum di suggerimenti degli utenti per fornire commenti e suggerimenti su come migliorare Servizi multimediali di Azure.Use the User Voice forum to provide feedback and make suggestions on how to improve Azure Media Services. È anche possibile passare direttamente a una delle categorie seguenti:You also can go directly to one of the following categories: