Adobe Access White Paper

Offline Viewing using Adobe® Access Packager and License Server Table of contents 1: Description 2: Adobe Access SDK 3: Adobe Access Packager Server—Content Encryption 5: Adobe Access License Server—Granting Viewing Rights 5: Content Delivery 6: Enforcing Content Protection Policies 11: Using Adobe Access SDK 14: Using External Programs and Libraries 17: Profiling Adobe Access with NetBeans 6.9 Development Environment 18: Video Player Development 18: For more information

Adobe Access 3.0 is a digital rights management platform that makes it possible to protect and securely deliver video and audio content for playback on consumer devices such as personal computers, mobile and connected TV devices. Adobe Access provides a range of monetization capabilities, while protecting video and audio content from unauthorized copying and playback.

In a previous article on the Adobe Developer Connection we discussed online streaming of Adobe Access protected content. In this article, we will focus on offline viewing of the content. Adobe Access provides: • Studio approved, industry-standard cryptography and robust tamper resistance provides secure playback of content • Persistent protection regardless of where the content is stored and independent of transmission method (HTTP streaming, RTMP, progressive download, download) • Anonymous or authenticated license acquisition • Support for a variety of business models: purchase (electronic sell-through), pay-per-view, rental, subscription or ad-based

• Support for standard A/V formats: H.264/MP4, AAC, FLV • Selectable Output Control enables the content owner to specify content protection requirements for analog and digital outputs to external displays, providing additional safeguards against unauthorized recording. Various technologies are used to control playback on devices, such as HDCP, CGMS-A, Rovi ACP (formerly Macrovision). This ensures reliable protection from copying at the output devices by protection of digital outputs (HDMI, DVI) and analog outputs (S-Video and Component Video). • Restricting video playback only to devices that meet specific criteria, such as device type (desktop, mobile, TV), OS, or hardware capabilities (hardware root or trust, no user accessible bus or UAB). • Limiting playback for each piece of content to specific SWF/AIR apps • Individualization, diversification, revocation, renewability—key studio DRM requirements. Adobe Access consists of the following components: Adobe Access Packager Server—content encryption subsystem Adobe Access License Server—licensing subsystem (based on the Reference Implementation) Adobe Access clients—bundled component of Flash Player and AIR

Adobe Access SDK Adobe Access is delivered as a Java SDK that provides the building blocks from which you can create a packaging server and a license server implementation. Using the SDK you can create a Adobe Access solution suited to your organization’s business model. The Java APIs provided in the SDK are:

Java APIs for managing domains These APIs are used to allow the server to handle client requests for joining and leaving domains.

Java APIs for protecting content These APIs are used to define rights and prepare content for distribution. The content protection APIs are: Policy management—The policy management API is used to create and modify policies to be applied to content. Policies can be created or updated, including getting/setting all usage rules and allowing additional parameters in a custom namespace. Content packaging—The content packaging API is used to encrypt content and retrieve metadata from the packaged content.

Adobe Access White Paper

2

Java APIs for issuing licenses These APIs are used when a client requests a license from the server. The SDK supports the following requests from the client: Authentication—The authentication API can be used to handle authentication requests and generate authentication tokens. License generation and acquisition—The license generation and acquisition API is used to generate a license for the user. Support for Adobe AIR version 1.5 clients and content—For the purposes of backwards compatibility, the SDK has APIs to handle requests from AIR applications created for use with AIR version 1.5 and earlier clients and protected content.

Reference Implementation The SDK includes a reference implementation, a simple Adobe Access deployment that demonstrates how to use the Java APIs. The reference implementation provides a License Server, Watched Folder Packager, Adobe Access Manager AIR application, and command line tools for content packaging and policy management based on the Java APIs.

Adobe Access Packager Server—Content Encryption Adobe Access Packager Server is designed for encrypting audio/video content and providing permanent content protection, regardless of content location. Adobe Access uses the same standards used to protect sensitive financial and personal data on the web, AES 128-bit symmetric content encryption and 1024-bit asymmetric public key infrastructure. Policy-based content protection helps ensure flexible content management (for example, limited content lease, offline viewing). You create Adobe Access policies in support of your organization’s business model, and then package your content using those policies. Once policies are applied to content during packaging, you can maintain control of your content no matter how widely it is distributed. The Adobe Access license server can then apply a video asset’s policies for all clients acquiring a license or overwrite the policy for specific client’s accessing that video.

Data Encryption Full or partial encryption of FLV and F4V content is supported, with three levels of encryption: • High—full content encryption • Medium—50% of the data is encrypted • Low—20-30% of the data is encrypted Encryption of content in Adobe Access is a single-thread process (it takes about 5 minutes to encrypt 4.7 GB of content by a server based on Intel® Xeon® CPU E5540 @ 2.53GHz). Encryption level is critical to your CPU utilization at content playback (decoding). The encryption process is run via a management console or Java interface. The Java SDK enables controlling content encryption using the following mandatory parameters: • source—content source name • dest—content destination name • policy—the specific policy to be enforced Other mandatory parameters are specified in the configuration files «adobeaccess-refimpl-packager.properties» and «watchfolder.properties»: «adobeaccess-refimpl-packager.properties» • licenseServerUrl—license server URL • resourcesDir—directory locating certificates and policies • password—password to open the packaging credential

Adobe Access White Paper

3

«watchfolder.properties» • video—enable/disable video data encryption • audio—enable/disable audio data encryption • script—enable script encryption • level—coding level As a result of content encryption, three files are created: • header—the header file • metadata—the metadata file • FLV/F4V—the encrypted content

Configuring The adobeaccess-refimpl-packager.properties configuration file is designed to manage the Adobe Access Packager Server. It includes the following parameters: • resourcesDirectory—the directory designed to store certificates and policies • LicenseServerUrl—license server URL • AsymmetricKeyOptions.Certificate—certificate used to encrypt the CEK in the DRM metadata, issued by Adobe • LicenseServerTransportCertificate—the transport certificate used for protection of communication with the license server issued by Adobe • SignatureParameters.ServerCredential—packager credential used to sign the DRM metadata, issued by Adobe • SignatureParameters.ServerCredential.password—password used to open the packager credential • watchfolder.interval—specifies how often the packager checks for new content to package in the watched folder • packager.watchfolder.overwrite—specifies whether an existing file should be overwritten if it already exists • watchfolder.source—the system directory used for automated encryption • packager.watchfolder.backupInput—enable/disable saving of the source file at batch encryption • packager.watchfolder.outputFileNameLabel—extension of the encrypted content • packager.watchfolder.backupSubfolder—the directory to store the original file The watchfolder.properties configuration file is designed to configure batch encryption and the level of file encryption (low, medium, high), as well as to manage the Adobe Access Packager Server. It includes the following parameters: • config.watchfolder.fileregexp—encrypted file search mask • MediaEncrypter.DRMParameters.KeyParameters.Policies.policyFile.1—the policy enforced at encryption • config.dest—the folder used to store the encrypted files • MediaEncrypter.DRMParameters.EncryptVideo—encrypt the video track • MediaEncrypter.DRMParameters.EncryptAudio—encrypt the audio track • MediaEncrypter.DRMParameters.EncryptScript—encrypt the script • MediaEncrypter.DRMParameters.EncryptVideo.level—encryption level For more details, please refer to the “Protecting Content” document. The document “Using the Adobe Access Reference Implementations” has additional details regarding the packager server.

Adobe Access White Paper

4

Adobe Access License Server—Granting Viewing Rights The Adobe Access License Server is designed to issue licenses that will grant rights to a client to decrypt video and audio content protected by Adobe Access. To play back the protected content, Flash Player 10.1 (or greater) or Adobe AIR 2.0 (or greater) is required. Flash Player 11 (or greater) or AIR 3.0 (or greater) is required to use all features available with Adobe Access 3.0. Adobe Access 3.0 introduces some new usage rules, which are not understood by Adobe Access 2.0 clients. By setting the minimum supported client version (HandlerConfiguration.setMinSupportedClientVersion()), the license server can control how older clients will behave when they encounter licenses with these usage rules. Based on this setting, the server can indicate whether older clients can ignore the usage rules they do not understand or whether older clients will not be able to consume licenses with those usage rules.

Content Delivery The Flash Player or Adobe AIR runtime client acquires a unique digital certificate (called a machine certificate) from an Adobe-hosted server. This process of assigning a unique certificate is called individualization. Individualization uniquely identifies both the computer and the Flash Player or Adobe AIR runtime used to playback content. The Individualization process allows the downloaded licenses to be bound to a specific computer on which the client is installed. Every computer is given a unique machine credential (machine private key and machine certificate). If a specific client were to become compromised, it can be revoked and barred from acquiring licenses for new content.

Content Delivery Process

When a consumer acquires protected content file from a website or CDN, the consumer must also acquire a license that contains a key to decrypt the video before it can be played. The following steps illustrate a common workflow for how protected content is accessed by a computer running Flash Player or Adobe AIR: 1. The consumer visits the retailer’s website, and selects a video to watch. The consumer attempts to download or stream the protected video to their computer using either Flash Player or an Adobe AIR application. If this is the first time the consumer has attempted to access protected content using this specific computer, the Flash Player or Adobe AIR runtime must first be individualized as described in Step 2. If the runtime client has already been individualized, the process of acquiring a license occurs as described in Step 3.

Adobe Access White Paper

5

2. The Flash Player or Adobe AIR runtime client acquires a unique digital certificate (called a machine certificate) from an Adobe-hosted server. This process of assigning a unique certificate is called individualization. Individualization uniquely identifies both the computer and the Flash Player or Adobe AIR runtime used to playback content. The individualization process allows the downloaded licenses to be bound to a specific computer on which the client is installed. Every computer is given a unique machine credential (machine private key and machine certificate). If a specific client were to become compromised, it can be revoked and barred from acquiring licenses for new content. 3. The client parses the protected content as it begins to download or stream to the consumer’s computer, and extracts the URL of the retailer’s License Server from the DRM metadata embedded within the file. The DRM metadata is typically separate from the content, such as embedded in an accompanying manifest file or as a binary blob, but can also be embedded within the content file. The client contacts the License Server at the specified URL, and acquires a license (as described below in Step 4). 4. The client acquires a license from the retailer’s License Server. During license acquisition, the client sends information identifying the requested content (the DRM metadata) and the machine certificate (identifying the consumer’s computer) to the retailer’s License Server. The license request sent to the server is encrypted using the Transport public key, which is also included in the DRM metadata. The License Server—which may be integrated into the retailer’s billing and authentication infrastructure— can perform a business rules check to verify that the user is authorized to view the requested content. If the business rules allow it, the License Server issues a license containing the content encryption key to decrypt the content and the usage rules associated with that user’s account. To process a license request, the License Server decrypts the request using its Transport private key. The CEK in the metadata is decrypted using the License Server private key, and re-encrypted to bind the license to the device making the request. The license is signed using the License server private key. The license response is signed using the Transport private key, and encrypted before being returned to the client. If allowed by the license, the client stores the license to enable offline access to the license. License caching allows the consumer to view protected content without reacquiring a license every time they want to view content. 5. Once the Flash Player or Adobe AIR runtime client has a license, the client extracts the CEK from the license, and the consumer can view the content they are authorized to access.

Types of Content Delivery Stream—viewing in real time, without having to download the content. Communication protocols: RTMP and HTTP Dynamic Streaming Download—to play back the content, the system downloads it to a local storage. Transfer Protocol: FTP, SMB, HTTP Progressive Download—the content is played back while being downloaded to a local resource. Transfer Protocol: HTTP

Enforcing Content Protection Policies Policies are used during content encryption, examples include: • User authentication • Determining license validity and expiry periods • Defining of the license caching term, enabling offline viewing of content • Determining the period of content use • Controlling the analog and digital outputs • Validating the current player is allowed to play this specific content (Player/Asset Controlling the players used to play back the content)

Adobe Access White Paper

6

Tools to Create and Change Policies To create, change and manage the policies, the following tools can be used: • Adobe Access Command Line Tools (create and manage) • Adobe Access SDK (create and manage)

Policy Rules A policy may include the following rules: • A start and end date for the policy—The start and end dates of a policy are specified at policy creation. After encoding the content using this policy, the content playback period is limited to those dates. After the expiration of the policy, the encrypted content cannot be played back. • The amount of time the policy is valid—measured in seconds—This rule takes effect after the content encryption. The content validity is counted down from the encryption time rather than the playback start time. • The time the user has to watch the content once they have started playback—(Also called the playback window)—measured in seconds—This is the period during which the user can view content (this period is counted down from the beginning of the first viewing and measured in seconds). • Whether access can be anonymous or requires authentication—This rule specifies whether user authentication is needed. If “requires authentication” is specified, it is assumed that the Adobe Access License Server would mandate from the Flash Player an AuthToken to authenticate the user. If the authentication is successful, a certificate is sent to the client to decrypt the content. • Whether to allow license caching—This parameter enables license caching to decrypt the content. Without license caching, every time the user attempts to play back the content, the license is requested from the Adobe Access License Server. This option is used to enable offline viewing. • License caching period (in seconds)—The license is not removed on PC restart. The license is removed if the browser cache is cleared. • License expiry date • Whether output protection controls are required on analog ports—Enabling content protection at output to external devices using analog ports (S-Video, Component Video). Please note that the laptop screen is not considered an external device by the system and you cannot limit output to it. • Whether output protection controls are required on digital ports—Enable content protection at output to external devices for digital ports (HDMI, DVI and UDI). Please note that the laptop screen is not considered an external device by the system and you cannot limit output to it. • Type of output protection control to apply (options are Required, Use If Available, Not Required and No Playback)—The following levels of protection are supported: Required—image output is possible only on devices supporting the technology, HDCP, CGMS-A, Rovi ACP (for the Windows OS only) Use if available—the video is shown on all devices, either supporting HDCP, CGMS-A, Rovi ACP or not supporting Not required—security technologies are not enforced, the video is shown on all output devices No playback—output to any external device is prohibited • Whether license chaining is supported—Enable license chaining • Check against white list of SWF or AIR applications allowed to view the content—Check the client software against the white list • Check against blacklist of client or runtime versions not allowed to view the content—Check the client software against the black list • You can also define custom properties for enforcing application-defined rights on the client—During packaging, custom properties can be defined. Such properties are passed to the server when you request a license; the license server can then validate those properties with a customer server addition

Adobe Access White Paper

7

Adobe Access Command Line Tools Adobe Access supports policy creation using the command-line utility «AdobePolicyManger». java -jar AdobePolicyManager.jar new

Adobe Access 3.0 supports several types of licenses. A leaf and root license are both generated from the same policy. The benefit of license chaining in a subscription model is that to renew an expired license, the server can issue a new root license, and it will renew all the leaf licenses associated with that root. The leaf license has the Content Encryption Key that is encrypted with a key in the root license. Policies are enforced when the client attempts to view protected content and enable limited offline viewing. To implement this feature, please specify the following parameters at policy creation: • license caching duration—for 24 hours -l 24

• caching end date—for midnight on December 1, 2012 -ldate 2012-12-1-00:00

After the caching duration has expired, at the next attempt of content playback, the player requests a new license: DRMManager.getDRMManager().loadVoucher(DRMContentData,LoadVoucherSetting.ALLOW_SERVER);

Policy Management To view and change properties of an existing policy, you can use the «AdobePolicyManager» utility which is part of Adobe Access package. With this tool, you cannot create policies with «custom» authentication. To do this, please use Adobe Access SDK instead (for details, please refer to section “Creating and modifying the policy”).

Viewing the policy parameters To view the policy settings, please enter: «java –jar AdobePolicyManager.jar detail »

Changing the policy parameters To change policy settings, type the command: «java -jar AdobePolicyManager.jar update -l 1440»

Adobe Access White Paper

8

Creating a list of policy updates To create and view a list of policy updates, you can use the AdobePolicyUpdateListManager utility which is part of Adobe Access. Configuring AdobePolicyUpdateListManager Utility To run the utility, add the following lines to the adobeaccesstools.properties configuration file: # File containing certificate to use to encrypt key (License Server Certificate) encrypt.keys.asymmetric.certfile=license.pem

# License Server URL (required) encrypt.license.serverurl=http://127.0.0.1

# Transport certificate for license server (required) encrypt.license.servercert= license.pem

# PKCS12 file containing credentials for signing content (Packager Certificate) encrypt.sign.certfile= license.pfx encrypt.sign.certpass=password

# PKCS12 file containing credentials for signing revocation lists (License Server Certificate) revocation.sign.certfile= license.pfx revocation.sign.certpass=password

To create a list of updates, please type: «java -jar AdobePolicyUpdateListManager.jar PolicyUpdateList.pol -u <наименование политики>»

Viewing the list of policy updates To view the list of policy updates, please type: «java -jar AdobePolicyUpdateListManager.jar -d PolicyUpdateList.pol»

Adobe Access White Paper

9

Changing the list of policy updates To add a policy to an existing update list, type the following command: «java -jar AdobePolicyUpdateListManager.jar PolicyUpdateList.pol -f PolicyUpdateList.pol -o -u

Policy revocation by policy name To revoke a policy, please type: «java -jar AdobePolicyUpdateListManager.jar PolicyUpdateList.pol -f PolicyUpdateList.pol -o -rf »

Policy revocation by Policy ID To revoke a policy by policy ID, please type: «java -jar AdobePolicyUpdateListManager.jar PolicyUpdateList.pol -f PolicyUpdateList.pol -o -r »

Adobe Access White Paper

10

Policy Update Management To enable policy update and revocation, do the following: • Open the adobeaccess-refimpl.properties configuration file. • Uncomment the line: HandlerConfiguration.PolicyUpdateList= For example: HandlerConfiguration.PolicyUpdateList=PolicyUpdateList.pol

• Uncomment the line that specifies the certificate to use for verifying the signature: #RevocationList.verifySignature.X509Certificate

• Restart the Adobe Access License Server with the Tomcat snap-in.

Using Adobe Access SDK Adobe Access SDK allows the developer to add the necessary functionality to the existing subsystems, create a set of relevant policies, and also enhance Adobe Access management and monitoring features. Policies are integral to the content protection system, providing for: Content protection—Regardless of the storage space, content is always in the encrypted format, and is decrypted blockwise (in RAM) during playback. Content management—Enforcing policies allows for flexible content management (for example, require authentication, track content lease for a limited time, offline viewing, control of analog and digital ports, control of players). Adobe Access offers the capability to create policies using the Java programming language and a set of Adobe Access SDK classes. Adobe Access supports two types of licenses: • Root • Leaf Here is an example of creating policy with support for license chaining: Policy policy = new Policy(true);

Here is an example of creation of a policy without license chaining: Policy policy = new Policy(false);

Authentication Types If you create a policy without specifying the type of authentication, the default type «UsernamePassword» is used in the command line tools. In the SDK, there is no default value—you must explicitly choose the authentication type. Three types of authentication are supported • Anonymous—No authentication required • UsernamePassword—mandatory username/password authentication through the Adobe Access authentication protocol • Custom—custom authentication Anonymous—no authentication during license request Here is an example of creating an anonymous policy: Policy pol = new Policy(false); LicenseServerInfo licServer = new LicenseServerInfo(AuthenticationType.Anonymous); pol.setLicenseServerInfo(licServer); // set rights and other policy attributes

Adobe Access White Paper

11

UsernamePassword—during the request, user authentication are carried out. The data is transmitted as login/password pairs. Here is an example of creating a policy demanding user authentication: Policy pol = new Policy(false); LicenseServerInfo licServer = new LicenseServerInfo(AuthenticationType.UsernamePassword); pol.setLicenseServerInfo(licServer); // set rights and other policy attributes

Custom—as the license requested, the AuthenticationToken with the user data is passed to the server. The client application has to implement the process for obtaining the authentication token, and that token is passed into setAuthenticationToken. The Adobe Access client does not automatically create the token. With custom authentication, the license server also must implement the token validation logic. Here is an example of creating a policy with the “custom” authentication: Policy pol = new Policy(false); LicenseServerInfo licServer = new LicenseServerInfo(AuthenticationType.Custom); pol.setLicenseServerInfo(licServer); // set rights and other policy attributes

For more detail of the process, please refer to the document: “Protecting Content.”

Managing the policy at the license server Adobe Access License Server allows you to manage/change the policy enforced on the license server side. By using the model of policy management at the server side, you can: • Apply anonymous policy for encoding , such as: «ad-policy», to protect the content. So there is no need to use a large number of policies with different parameters. • Reduce the complexity of your project through centralized policy management • Have no need to update policy on the client side, reducing the network traffic and server load • Flexibly manage the policy settings at each license request for each user and playback device • Simplify the possibility of functional upgrade, such as adding geo-filtering, monitoring SWF-applications, etc. • Enjoy enhanced events logging. Policy Management at the server side is also implemented by Adobe Access Server for Protected Streaming, and all playback restrictions are also managed by the server. Please find a detailed description in the document: “HTTP Streaming with Dynamic Adobe Access Protection.” An example of policy management at the license server side: Regardless of the policy used to encrypt the content, the license server limits license caching to no more than 5 minutes. This prevents enforcement of policies with invalid parameters or granting of unlimited access. Setting the limits by “mediaPolicy.setRights (…)” makes it possible to set “ApplicationRequirements” right at the moment of license request.

Adobe Access White Paper

12

Example: PlayRight play = new PlayRight(); play.setPlaybackWindow(play.PLAYBACK_WINDOW_UNLIMITED); private static List rightsList = new ArrayList(); rightsList.add(play); for (Policy mediaPolicy : policies){ // Try all policies to find if any would allow generating a license. License.LicenseType desiredLicenseType = determineDesiredLicenseType(licenseReq, mediaPolicy); try{ mediaPolicy.setLicenseCachingDuration(300); mediaPolicy.setRights(rightsList); licenseReq.setSelectedPolicy(mediaPolicy); return licenseReq.generateLicense(desiredLicenseType) }catch (PolicyEvaluationException e){ error = e; }catch (LicenseGenerationException e){ error = e; } }

Managing players at the license server side Adobe Access SDK provides the capability to expand the existing license server functionality (Reference Implementation) to control the SWF applications used. You can control SWF applications by SWF URL or SWF hash. There is an API to calculate the SWF hash based on a particular SWF file. The client enforces the SWF URL or SWF hash: • SWF application URL, for instance: http://127.0.0.1/appl/player.swf An example of implementing application control at the license server level 1. Insert the list of allowed SWF applications in the «adobeaccess-refimpl.properties» configuration file: • RefImpl.srvPolicy.swfPath.1=C:/Program Files/Adobe/Flash Media Server 4/webroot/player/OSMFPlayer.swf • RefImpl.srvPolicy.swfPlayerURL.1=http://127.0.0.1/player/OSMFPlayer1.swf 2. To the «RefImplAbstractReqHandlerServlet» class, add a call of a class to populate the list of SWF applications, e.g., “PolicyConfiguration” 3. Add a function to process policy constraints when requesting a license, for example: Collection arraylist = new ArrayList(); ApplicationRequirements appReq = new ApplicationRequirements(); SWFHash swfHash = null; FileInputStream in = null; for(int i = 0; i < getPolicyConfiguration().getSwfPlayerFileName().size(); i++){ try { in = new FileInputStream(….); int maxVerifyTime = 60; swfHash = new SWFHash(in, maxVerifyTime); arraylist.add(new SWFApplicationIdentifier(swfHash)); } catch (IOException ex) { java.util.logging.Logger.getLogger( PolicyParams.class.getName()).log(Level.SEVERE, null, ex); } finally{ if(in != null) in.close(); } } for(int i = 0; i < getPolicyConfiguration().getSwfPlayerURLName().size(); i++) arraylist.add(new SWFApplicationIdentifier(getPolicyConfiguration().getSwfPlayerURLName().get(i).toString()));

Adobe Access White Paper

13

4. Add the “requirement” for the resulting policy: mediaPolicy.setRights(arraylist);

Adding Geo-Filtering to the License Server To add Geo-filtering to the license server, please create a handler function to validate the input parameters and the client’s IP-address, at an external Geo-filtering service, for example: URLConnection conn = null; DataInputStream dis = null; DataOutputStream dos = null; boolean authValid = false; try { conn = new URL(“http://...”).openConnection(); conn.setDoInput(true); conn.setDoOutput(true); conn.setUseCaches(false); dos = new DataOutputStream (conn.getOutputStream()); URLEncoder.encode(addTextField.getText()); String msg = “” + “” + “” + “” + request.getRemoteAddr() + “” + “” + authToken + “” + “” + “”; dos.writeBytes(msg); dos.flush(); dos.close(); ….

Using external programs and libraries Adobe Access SDK can expand the features of an existing license server. Using the Java programming language and the RRDTool software, you can keep the Adobe Access License Server statistics in a simple visual format, e.g., as a graph:

Adobe Access License Server statistics (license requests)

Adobe Access White Paper

14

Extending the capabilities with JMX The JMX technology (Java Management eXtensions) allows Java developers to integrate their applications with the existing network management solutions. An example of JMX use is the JConsole application, bundled with JDK (for more detail, please refer to “JConsole” monitoring utility”). With JMX objects (MBeans), you can expand the existing monitoring capabilities of Adobe Access. Using this interface to control the Adobe Access License Server you can: • Avoid memory leaks (GarbageCollectorMXBean interface) • Avoid hard disk space shortage (RuntimeMXBean) • Monitor the CPU status (Runtime interface) and memory interface (MemoryPoolMXBean)

Adobe Access License Server statistics (CPU utilization) Example of using the Java MXBean interface to monitor CPU and RAM

Adobe Access License Server statistics (RAM utilization)

Adobe Access White Paper

15

Logging events with Log4j To ensure correct and stable operation of Adobe Access, monitoring of the application parameters and registration of critical alerts are needed. To track the application status, you can use the Log4j library. It can log the alerts both to files and network resources, e.g., syslog. Event levels: • ALL—logs the entire record • DEBUG—is designed for application debugging • INFO—is most often used for logging events in the application • WARN—tracks the situations potentially dangerous for the application • ERROR—identifies serious application issues the application can still run with • FATAL—occurs at the most critical issues that crush the application • OFF—logging disabled An example of message logging: private static final Logger log = Logger.getLogger(Класс.class); log.debug(“start”); try { …. } catch (Exception e) { log.error(“failed”, e); } log.debug(“done”);

JConsole monitoring utility JConsole utility is a JMX-compliant application bundled with JDK. JConsole allows you to monitor the OS and JVM parameters both at the local and remote machines. To monitor JVM on the local machine, at launching JConsole it is sufficient to specify the Java application PID in the startup parameters: jconsole [PID] To monitor JVM on the remote machine, at launching JConsole, please specify: • remote host name • network port jconsole [hostName:portNum]

JConsole Window

Adobe Access White Paper

16

JConsole Main Window http://download.oracle.com/javase/1.5.0/docs/guide/management/jconsole.html

Configuring Tomcat to interoperate with JConsole In order to monitor the parameters of Tomcat and Adobe Access, in the catalina.sh file (OS Linux): • Comment out the line: JAVA_OPTS=”$JAVA_OPTS -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager”

• Insert the line: JAVA_OPTS=”$JAVA_OPTS -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dcom.sun. management.jmxremote.port=2002 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management. jmxremote.authenticate=false -Djava.rmi.server.hostname=127.0.0.1”

Profiling Adobe Access with NetBeans 6.9 Development Environment With Adobe Access SDK and IDE Netbeans 6.9 development environment, you can run Adobe Access License Server under Netbeans 6.9 in the profiling mode to have better insight into the application behavior. With profiling, you can visualize the application status, i.e. threads, memory, CPU, while tracking the application behavior (for instance, when requesting licenses).

Main window of IDE NetBeans

Adobe Access White Paper

17

Video Player Development Adobe Access can expand the system functionality based on flexible management of content playback. Using the existing OSMF framework as the basis for client development, you can: • Tailor the existing implementation of the player to a specific project, at no additional cost on low-level design • Use time-tested mechanisms to control playback and track events • Leverage extended Flash programming with ActionScript3.0

Offline Content Viewing Implementation To enable offline content viewing at the client (player) side, obtaining and caching of licenses must be enabled. DRMManager.getDRMManager().loadVoucher(DRMContentData, setting);

Caching time is independent of the player implementation and is determined by the parameters of the policy enforced at content encryption. The «setting» parameter indicates where the player should look for a license - either locally or at the server.

The following types of license management have been defined: • LoadVoucherSetting.FORCE_REFRESH—the voucher is always loaded from the server. • LoadVoucherSetting.LOCAL_ONLY—the voucher is loaded from the local cache only. • LoadVoucherSetting.ALLOW_SERVER—if possible, the voucher is loaded from the local cache, otherwise it is downloaded from the server. Enabling user authentication If content playback requires user authentication, it is necessary to provide for creation of login / password pair and pass it to the Adobe Access License Server for authentication purposes. DRMManager.getDRMManager().authenticate(DRMContentData.serverURL, DRMContentData.domain, username:String, password:String);

To check for the results of the authentication attempt, please listen to the authenticationComplete and authenticationError events. User authentication requirement is a mandatory parameter and can not be ignored by the player.

Authentication Token Implementations To transfer user data to the license server, please create and send an authentication token. The data is passed to the server at license request. var ba:ByteArray = new ByteArray(); ba.writeUTFBytes(“testToken”); DRMManager.getDRMManager().setAuthenticationToken(DRMContentData.serverURL, DRMContentData.domain, ba);

For more information Adobe Access details: www.adobe.com/go/flashaccess Flash Media Server details: www.adobe.com/go/flashmediaserver Contact information and licensing inquiries: [email protected]

Adobe Systems Incorporated 345 Park Avenue San Jose, CA 95110-2704 USA www.adobe.com

Adobe, the Adobe logo, Adobe Access, Flash Media Server, ActionScript, and Flash Professional are either registered trademarks or trademarks of Adobe Systems Incorporated in the United States and/or other countries. Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Java is a trademark or registered trademark of Sun Microsystems, Inc. in the United States and other countries. All other trademarks are the property of their respective owners. © 2012 Adobe Systems Incorporated. All rights reserved.

91070945 4/12