This post is a step by step walkthrough of using the Azure Media Services Explorer (http://aka.ms/amse) to apply AES encryption to a video asset. I’ll describe the full process of applying envelope (AES) encryption and providing a JWT token with claims authentication. Note that while this article specifically discusses AES, some of the same principles apply to other DRM like PlayReady, Widevine, and FairPlay as far as the token authentication goes.
Whenever you’re changing the format of video or encrypting it, the first thing you should understand is what clients support that video format or encryption type. With the Azure Media Player we have a compatibility list available at http://amp.azure.net/libs/amp/latest/docs/index.html#compatibility-matrix. This lists OS and browser combinations and what playback mechanism is supported with unencrypted, envelope (AES), and DRM (PlayReady/Widevine/FairPlay). Since we’re focusing on AES here, the middle column of the compatibility matrix lists what the expected tech is and whether or not the OS/browser combination is supported. For example, with the Edge / IE 11 browsers on Windows 10 the azureHtml5Js tech is used to play AES encrypted content. You can find more about the techs at http://amp.azure.net/libs/amp/latest/docs/index.html#playback-technology-tech-. For modern OS’s and browsers AES is the lowest common denominator for encryption. But keep in mind that iOS 6+ with Safari and Android 4.0 with Chrome 37+ doesn’t support Token authentication without a token proxy. We’ll have to go back to the player docs once we have the token so that you know how to pass the token to the Azure Media Player.
Related Articles
Now that we know what browsers are supported you’ll need to encrypt the asset. I’m performing all of the media processing in Azure Media Services Explorer (http://aka.ms/amse). First we’ll upload and encode an asset. I’m encoding the asset with Media Encoder Standard with the Content Adaptive Multiple Bitrate MP4 encoding profile. This allows us to stream the output. To encrypt the asset with AES:
- Right click on the output asset and choose Security / Add dynamic encryption and key delivery policies to the asset(s)…
- For Protection choose Envelope clear key.
- For Delivery I recommend checking Enable dynamic encryption and checking all three delivery protocol boxes (HLS, DASH, Smooth Streaming).
- On the next dialog for AES Key Generation I recommend using Automatic generation (random content key).
- On the next dialog if you have an external key server, feel free to use it, but it’s easier to use Azure Media Services for this.
- Next set the Key Delivery From Azure Media Services to Yes and use only one policy. Since you’re using AMS for the license acquisition you don’t need the Key Acquisition URL set.
- With AES on the next dialog you have two options for the Content key’s authorization policy option. The Open option does not require any authentication. If you don’t care who views the video, but just want to encrypt it then this is the option to choose. If you want to authenticate viewers then choose Token. That’s what we will focus on here.
- In this example for the Token Type we will choose JWT – JSON Web Token with symmetric key.
- For Token Properties set the issuer and audience. Typically for the Issuer it will be your company’s web site. The Audience or scope will be a subset of who you want to have access to the video. This allows you to specify different groups that can have access. For example, if you wanted only the marketing team to have access you could set it to urn:marketing assuming you have a way of providing a token only for people from the marketing team.
- You can specify additional claims if you wish.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1cm46bWljcm9zb2Z0OmF6dXJlOm1lZGlhc2VydmljZXM6Y29udGVudGtleWlkZW50aWZpZXIiOiI5ODFkN2YzNC1iYmVhLTQ0MzgtYTVkMi1kZDkyNzQwYTYyYjciLCJpc3MiOiJodHRwOi8vZGJyaXN0b2wuY29udG9zby5jb20vIiwiYXVkIjoidXJuOmFsbGNvbXBhbnkiLCJleHAiOjE1MDQxMTYyMjZ9._WSfzDk5P23KjbAtJWdcEnr5L77t1OxkiIHbtYyjBRA
On the Content keys tab you can get a new test token and specify the expiration and other options if you wish. This process is of course manual and not helpful outside of testing. For a full workflow you would want to run your own token generation service as part of your website. There’s a number of third party options for doing that. I’d suggest just searching for options on that https://www.bing.com/search?q=jwt+token+service. But essentially the idea is:
- You validate that a user logged into your website has a valid account (simply by logging in).
- You figure out what group / audience they’re part of if needed.
- You build the token payload that includes the following fields:
a. urn:microsoft:azure:mediaservices:contentkeyidentifier – (Required) This identifies specific key to unlock. Without this value the service would not know what to issue a key for.
b. iss – (Optional) The issuer of the token.
c. aud – (Optional) The audience / scope that I explained before.
d. exp – (Optional) This is the JWT token expiration. You should expire it, otherwise it could be reused by someone else.
e. nbf – (Optional) This is essentially a start time, or “not before” time. Used along with exp this gives you a time range that the JWT token is valid. - When generating the signature you just need to sign it based on the symmetric key of the asset. If you’re in Azure Media Services Explorer, this is on step 3 of adding dynamic encryption to the asset on the dialog where you’re setting the Token Type, but on the Symmetric token key tab. Because you are signing your token based on this key you will need to keep this in your database. In AMSE you can get the symmetric key after encryption by double clicking on the asset, going to Content keys, selecting the Token option and clicking on the See key value button next to Primary Verification Key.
FoEn89xKyFYZaE8fwXL2CeMKodS+AdS6qsufwKn2pBJcG293EKJFCGThHXgWlEWrGXleMw9J4lz77fIQ9ACIvw==
This post first appeared on MSDN Blogs | Get The Latest Information, Insights, Announcements, And News From Microsoft Experts And Developers In The MSDN Blogs., please read the originial post: here