Microsoft Azure Stack is an extension of Azure—bringing the agility and innovation of cloud computing to your on-premises environment and enabling the only hybrid cloud which allows you to build and deploy hybrid applications anywhere. We bring together the best of the edge and cloud to deliver Azure services anywhere in your environment.

It is notable that the dynamic PlayReady protection feature in Azure Media Services makes “one-click DRM” a reality: customers or partners do not need to go through any of the following steps which are required in "traditional DRM":

How to Run It?

Check “Add AuthN ACS Token” checkmark so that ACS authorization token will be requested first and will be used in PlayReady license acquisition from the license acquisition URL specified in LA_URL text box;

Set up an Azure ACS 2.0 namespace to authenticate the player client and issue authorization tokens;

Develop a Silverlight player which handles authentication, authorization, license acquisition and video playback.

Content Key Generation

There are various approaches in generating content key IDs and content keys. For a detailed discussion, please see the author’s blog (Key Generation and Management section). For example, there are the following ways:

//Method 2: With a given key seed and generated key ID (Key Identifiers are unique in the system and there can only be one key with a given Guid within a cluster (even across accounts for now although that may change to be account scoped in the future). If you try to submit a protection job with a keyId that already exists but a different key value that will cause the PlayReady protection job to fail (the same keyId and keyValue is okay).
keySeedB64 = "XVBovsmzhP9gRIZxWfFta3VVRPzVEWmJsazEJ46I";
contentKeyB64 = GetPlayReadyContentKeyFromKeyIdKeySeed(keyId.ToString(), keySeedB64);

The following utility methods are used in generating key ID and key seed:

public static byte[] GenerateCryptographicallyStrongRandomBytes(int length)
{
byte[] bytes = new byte[length];
//This type implements the IDisposable interface. When you have finished using the type, you should dispose of it either directly or indirectly. To dispose of the type directly, call its Dispose method in a try/catch block. To dispose of it indirectly, use a language construct such as using (in C#)
using (var rng = new System.Security.Cryptography.RNGCryptoServiceProvider())
{
rng.GetBytes(bytes);
}
return bytes;
}

ACS Setup

End users are authenticated by an Identity Provider to gain access to the web application hosting the player, the so-called Relying Party. In this prototype, we have chosen to leave the web application open without the need for user authentication. Therefore there is no need of an Identity Provider for the web application.

Client/autonomous applications are authenticated by ACS 2.0 namespace to gain access and acquire tokens. For this purpose, we specify a Service Identity to authenticate directly with ACS instead of using an Identity Provider. This Service Identity is then used by client to get authenticated by ACS in order to request authorization token from the ACS namespace.

NOTE: Please make sure that the same (primary) symmetric hash key used in ACS 2.0 namespace is also used in configuring PlayReady dynamic protection. Specifically, when you programmatically set up PlayReady dynamic protection, you need to create Restriction Requirements used in IContentKeyAuthorizationPolicy, as shown below.

The primarySymmetricKey variable should contain the same symmetric hash key string as obtained from ACS 2.0 Management Portal as shown below:
When you create Service Identity in ACS namespace, you may choose either Password or Symmetric Key credential types. The token request code has been enhanced to support both cases.

Code on Client Side

The client side code for requesting authorization token from ACS and the custom license acquirer inside Silverlight can be found in GitHub Azure/azure-media-services-samples.
Player application performs the following:

First request the manifest of a smooth streaming asset under PlayReady protection and sees the protection header in the manifest;

In order to request PlayReady license, the player needs to get the authorization token from ACS namespace created in the last section. To avoid writing too much Silverlight specific code, you may consider putting this code in a (WCF or REST) service and let Silverlight app call the service to get ACS token. After you get the ACS token, you may store it in a property (Constants.AcsToken) to be used by the license acquirer immediately after.

The ACS token is then used by a custom license acquirer to acquire a PlayReady license from AMS license delivery service configured in a previous section.

Deployment

As described in the system diagram above and the author’s blog, this end-to-end prototype contains the following physical components:

Since the solution is built on Azure Media Services, the only thing you need to deploy is the ASP.NET web application hosting the video player. You have the options to deploy it in

Azure web site,

Azure IaaS VM, or

your on-premise server.

Please make sure that HTTP process activation is installed on the server otherwise WCF service will not work properly. Also please make sure you configure at least 1 RU for the streaming origin to use PlayReady dynamic protection.

What about Live Streaming?

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 the “VOD asset”.
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. To create the program, you need to create an asset which will contain the live archive for the program. 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. The following code shows the precise flow.
As shown in the code for Azure Media Services, we use the following method to set up dynamic PlayReady protection for a VOD asset:

To set up dynamic PlayReady protection for a live streaming, we can create a channel, a program and its asset as usual, but before starting the program, we run the above method against the asset, as shown below.

It now works with any Azure ACS namespace instead of just the ACS namespace used for the end-to-end implementation discussed in this blog;

It works with any smooth streaming or MPEG-DASH assets, either open or under dynamic PlayReady protection with or without token restriction;

It works with any PlayReady license server, either key delivery service in Azure Media Services or on premise PlayReady license servers.

On 1/23/2015: With the release of JWT support in AMS Content Protection, this prototype has been expanded to include token restriction with JWT by using Azure Active Directory (AAD) as both STS and IdP. AMS batch job (for setting up dynamic PlayReady protection or AES encryption): knows AAD tenant, but nothing about player app (any player is fine). AAD tenant: knows player app, but nothing about the AMS batch job. Player app: knows AAD tenant, but nothing about AMS or AMS batch job. In order words, AAD tenant and player app know each other. AMS batch job knows AAD tenant, but does not care what player consumes the contents.
ACKNOWLEDGMENT:Special thanks to Quintin Burns, George Trifonov and Mingfei Yan of Microsoft Azure Media Services Team, who have provided significant help in this effort.