Today I want to introduce you to one of the most flexible ways of getting a DRM license from the KeyOS MultiKey License API and this may push you towards setting up the License Acquisition Proxy, or just proxy on your side as many our customers did already.
Authentication XML and License Acquisition Strategies
If you have read our previous blogs, you may already know that to acquire a license from the KeyOS MultiKey License API you will require a Security Token which we call the Authentication XML.
The Authentication XML must be sent to the KeyOS MultiKey License API in a custom POST header during the license request made by your playback client.
There are different ways of how to get the Authentication XML for later use in a license request.
These ways differ in their implementation complexity and cases or playback clients you can use them with. For example, you may be writing your web portal with the player in it. In this case, you could implement a simple direct Authentication XML injection during page rendering quite easy and move on with our tests or even go into production after adding some additional security measures to the Authentication XML. But, if, for example, you are working on an Android native app which is supposed to playback DRM protected assets, then you would need either a backed API or a proxy method in place because the Authentication XML can only be generated on a server-side for security reasons.
Here are different methods of getting the Authentication XML for later license acquisition:
- Direct injection – a very simple method of pre-generating the Authentication XML and inserting it into your playback client directly. Mostly used on the web when rendering the web page.
- You pass the pre-generated Authentication XML into your playback client during page rendering, or you generate one dynamically using your script and you pass it into the playback client.
Whilst this may be good for testing and debugging your solutions, this is not advisable for production scenarios.
- Backend API – a way of getting the Authentication XML from the backed API on your side. The idea is to send some data to your API and get the Authentication XML in response. Once the Authentication XML acquired you pass it to the player. Figure 1.
Figure 1: Getting the Authentication XML from the backend API
The backend API method is used on the web or in native applications (since the client can’t generate the Authentication XML it must request one from the server).
- License Acquisition Proxy – a way of getting a license through a proxy script on your server. Where is the Authentication XML you may ask – it is generated by the proxy when needed. This method gives you the most control over the license acquisition process. It allows for the data collection on the server-side. It allows supporting playback clients that don’t allow setting custom POST headers during license requests.
When this approach is used:
- You set up your playback client to point to a script on your server which acts as a proxy.
- The player makes a license request to the proxy.
- The proxy validates the request and appends it with the Authentication XML.
- The license request with the Authentication XML is sent to the KeyOS MultiKey License API.
- The license is generated and sent back to the proxy and then to the client.
Please, refer to Figure 2 below to see the process:
Figure 2: Getting a license through the proxy
Looks Complex. What are the benefits?
There may be different cases in which the proxy is the only way to move forward. For example:
- You are using a playback client which doesn’t allow you to set the custom POST header when requesting a license.
- You need to allow machines from your internal network to acquire a license from the internet, and you must point these machines to your gateway computer which is the only one who has access to the outer world.
You may also want to collect data for your reports. For example:
- The number of issued licenses.
- The number of failed licenses.
- The asset played the most by the end-user.
Another thing you can do is optimize your license acquisition speeds. Because the Authentication XML doesn’t need to be unique when using a proxy, you may implement caching mechanisms to get your Authentication XML from a cache instead of generating it dynamically for similar requests. You can also implement a keep-alive connection to the KeyOS MultiKey License API to save time on establishing a handshake on every request. You can read more about bottlenecks during license acquisition and how to shave some time of them in our recent blog (https://go.buydrm.com/thedrmblog/speed-up-your-streaming-with-low-latency-drm).
Besides your technical boundaries or business requirements, or better license acquisition timings, the proxy approach is less prone to Authentication XML expiration errors and is more secure w/o the necessity of adding additional binding rules to the Authentication XML.
Below, is a comparison table (Table 1) which shows proxy’s advantage over the other two methods:
Table 1. Authentication XML/License acquisition methods comparison
Where can I read more?
If you are interested in setting up the license acquisition proxy, you can read more in the KeyOS Wiki in your KeyOS Account. The wiki has code samples in different languages that you may find useful. And if you have any questions, please, let us know by creating the ticket.
Thank you and see you next time.
