GravityLab Multimedia Inc. Windows Media Authentication Administration Guide

GravityLab Multimedia Inc. Windows Media Authentication Administration Guide

Token Auth Menu GravityLab Multimedia supports two types of authentication to accommodate customers with content that requires permission before viewing. The first type of authentication is when the Customer Origin is password protected at a site level or directory level. Examples of this type are when using file system user management to password-protect a website, a directory, or using.htaccess password protection within Apache. We refer to this method as Server-Based Authentication, since the web server is the point of authentication. The second type of authentication is application-based authentication that can accommodate the display of content at a very granular level using tokens. We refer to this as Application-Based Authentication since the customer application is performing the authentication. Regardless of the password protection scheme used when the file is being served from the origin, the origin server can send a header telling the edge servers to re-validate the request. This is a standard header and is constructed as follows: cache-control: must-revalidate or cache-control: proxyrevalidate. GravityLab Token Authentication (application-based) When a user visits and logs into a customer s web application, the application can generate and place a randomized encrypted token at the end of the URLs of objects that are for display using the GravityLab content delivery network. Token authentication is now available for all content types, including HTTP, Windows Media and Flash Media Streaming. Please consult your Media Control Center for more information. These tokens can be set to include any kind of information necessary for the customers business objectives. For example the token can contain: The session ID A user identifier Authorized referral link

Length of time for the user to view the file. (i.e. 24 hours) Customers should configure their origin server to set the header for any file that requires authentications to cache-control: must-revalidate. Once a request for a file goes through the edge servers, the edge servers will send a request to your Origin Server. Customers must check the URL being requested, parse the URL and get your randomized encrypted token. If the token meets their criteria they can send back a 200 status header so that the EdgeServer can display the requested object. If the token does not meet the desired criteria, or if the token is missing or invalid, then you can send the 404 access denied header. Example: In your web application you can add the following token to the end of the desired objects to be authenticated: Token Value: IP Address Encrypted Token: encrypt( ClientIP + rand string ) = d5qhvglbefrm Your actual link will be similar to: http://movies.domain.com/000002/domain.com/movie.avi?sd5qhvglbefrm The origin server would then decrypt the value d5qhvglbefrm to derive at: ClientIP234893. Parse out the random string 234893 and send the appropriate headers to validate the request. Creating Tokens in the Media Control Center Users will need to access the Media Control Center to configure the Token Auth application to their desired settings. Users will need to create a secure keyphrase in the Media Control Center so the token authentication algorithm can secure the content. Users will also need to add the directories which will be protected by the Token Authentication offered by GravityLab.

Windows users can create directories from directories in either GravityLab storage or on their own origin. Users will only need to specify the name of the directory for the content to be protected, as well as content within any folders under the protected directory. te that this behavior may vary from other GravityLab platforms. GravityLab offers a wide variety of authentication methods to protect users content. Tokens may be configured to check against last-modified times, enduser IP addresses and HTTP referrers. Tokens may vary by file type, so please consult the Media Control Center for the most up-to-date listing of available tokens. Users can create individual tokens by entering the values in the appropriate box followed by pressing the Generate Encrypted URL button. Users may configure their tokens with several of the available parameters for a given token. Also note that token authentication binaries are available to generate tokens programmatically. GravityLab may also offer by request, the source code necessary for a user to create their token authentication script. The following diagram outlines the decision tree process that occurs during authentication as well as the three different HTTP codes that can be returned by the origin server. These codes are: This code will be returned by origin server if the request is authorized. The GravityLab server will go ahead and cache the file. 304 t Modified The code will be returned by the origin server if the request is authorized and if the file on the origin server has not been modified since it was last cached. GravityLab will then serve the content to the requestor from the cache. 403 Permission Denied

The code will be returned by the origin server if the request is not authorized. The requestor will be denied access entirely to the requested object and there will be no check of the cache for content freshness.. User request Content in Cache? Edge Server to Origin: Send URL + Token Authenticate Content Authenticate or public? Public Edge Server to Origin: Send URL + Token TTL or Expired? 403 Perm. Denied 403 Perm. Denied cache-control: must-revalidate cache-control: must-revalidate File cached to Edge servers once retrieved from origin File cached to Edge servers once retrieved from origin Application based authentication File delivered to client Figure:

Server based Authentication The GravityLab edge server will pass HTTP headers back to the origin server which allows the origin server to give permission to either accept or reject a request to download content. This process will also enable the edge server to update the file if it has been modified. User request Content in Cache? Edge server requests to origin Http://www.domain.com/movie.avi Movie.avi Modification? 403 Permission Denied 403 Permission Denied 304 t Modified File cached to Edge servers once retrieved from origin File cached to Edge servers once retrieved from origin GravityLab Server based Authentication File delivered to client Figure: