Adobe Licensing in Secure Environments

Posted on by

This technical article is aiming to provide an insight about Adobe Licensing in Secure Environments and it’s a more in-depth analysis about the Adobe Named User Licensing and Adobe Feature Restricted Licensing we previously presented.

Introduction and Overview

Adobe’s new licensing infrastructure for device-based applications supports two different mechanisms for application licensing. The first licensing mechanism, Named User Licensing (NUL), provides:

  • Access to World-class creative & productivity apps, including the latest cloud first applications such as Adobe XD, Lightroom CC and Adobe Dimension. These applications are not available with any other licensing method, including Feature Restricted Licensing.
  • Cloud Services to help you accerate. Jump-start projects with anywhere, any-device access to assets in Creative Cloud Libraries, cloud collaboration using Team Projects, and font collections from Adobe Typekit. Automate signature driven workflows and deliver a faster return on signed documents with Adobe Sign.
  • Enhanced security and control. Get enterprise-level security with advanced user identity management, including Single Sign-On (SSO), and protect assets with at-rest and in-transit encryption.
  • Licence management – Easily manage users and deploy apps throughout your organization.

Named User Licensing is designed for any network-connected situation where application licenses are managed based on individual user need for use of the application.

The second licensing mechanism, Feature Restricted Licensing (FRL) is used when access to Adobe applications must be assigned to a computer rather than the individual users of that computer. Examples of where Feature Restricted Licensing might be used include computers:

  • in a kiosk-style configuration where individual users do not log in;
  • on a LAN in a secure network that doesn’t connect to the internet; and
  • in an isolated (off-network) secure facility.

This document describes two licensing mechanisms, and provides the technical details needed for customers to evaluate their applicability to their specific deployment environments. Diagram 1 provides an overview of the mechanisms and all their variants. Then the specific of Named User Licensing are detailed, followed by those for Feature Restricted Licensing.

Adobe Next Generation Licensing mechanisms overview
Diagram 1 – Next Generation Licensing mechanisms overview.

Adobe Licensing in Secure Environments – Named User Licensing

In this treatment of Named User Licensing, the assumption is that the customer has already established Federated Authentication with Adobe. This means that the customer has established ownership of one or more internet domain names (e.g., dmv.dc.gov, nike.com), has pre-created accounts for the customer’s users each with a unique user ID (e.g., usr529357@boeing.com, dbrotsky@adobe.com), and registered the internet addresses of customer-specific authentication servers that are authoritative for the customercontrolled domains. There is no need to pre-configure computers for Named User Licensing other than to install any desired applications. Each of the computers to be licensed must have access to the internet, but that access can be controlled by a firewall device that intercepts and unpacks all network traffic to verify its content and ensure that:

  • no unauthorized data is sent outside the internal network;
  • all transmitted data is sealed inside of an encrypted tunnel between the firewall device and the Adobe servers; and
  • the endpoint of every transmission is an authorized Adobe server with a known network address and a publicly signed, non-revoked SSL certificate.

Named User Licensing takes place in two phases:

Authentication. In this phase, which uses the industry standard SAML protocol, a user uses a web browser to authenticate against a trusted server run by the customer, which then informs Adobe which user is logged in. At the end of this phase, a user-specific credential, called a device token, is put into the OS-user credential store.

Licensing. In this phase, a copy of the device token is validated by Adobe and exchanged for a license packet that permits the user to use his licensed applications. At the end of this phase, the license packet is put into the OS-user credential store.

Because each phase of Named User Licensing ends up caching information in the OS-user credential store, users who have licensed an application can continue to use the application even if the computer goes off the network. The cached information will be revalidated whenever the computer comes back on the network, so that changes made by the customer to which users can use which applications, and/or changes in which users are allowed to authenticate, take effect on the computer immediately whenever the computer is online.

Diagram 2 depicts all the steps in both phases. Detailed descriptions of each step are found below the diagram.

Adobe Named User Licensing workflow schematic
Diagram 2 – Named User Licensing workflow steps.

Authentication phase

The authentication phase determines the federated user identification of the OS user currently logged in on the customer computer:

  • When an application launches, it will look for a previously cached device token in the OS credential store. If it finds one, the authentication phase is complete, and the licensing phase begins (next section).
  • The application makes a call to the Adobe licensing server to request an authentication endpoint. This call contains the following data about the computer on which the application is running:
    • an Adobe-generated machine ID which is a SHA-256 hash of various computer characteristics, such as motherboard serial number and/or boot disk serial number;
    • the OS hostname, OS type, and OS version (which are recorded only for the customer’s internal accounting purposes).
  • This call returns an Adobe signed packet containing a URL for an authentication page hosted on an Adobe Authorization server.
  • The application opens this URL in an embedded web browser window, and receives an authentication prompt asking for the user’s email address. The user need only enter his email domain (e.g., dmv.dc.gov); he need not give his full email address (and Adobe need not know it).
  • Once the user’s domain is known, the Adobe Authorization server redirects the browser to the customer’s internal authentication server (which was previously registered with Adobe for that domain), sending it a SAML request to authenticate the user.
  • The customer’s authentication server authenticates the user and redirects the browser back to the Adobe Authorization server with a SAML assertion identifying the user. The Adobe Authorization server generates a device token for the user and the computer and returns it to the browser in the application.
  • The application stores the returned device token in the OS user credential store. The user is now authenticated.

Licensing phase

The application now has a device token, either acquired from the Adobe authorization server or retrieved from the OS user credential store. It then goes through these steps to acquire a per-user license:

  • The application makes a call to the Adobe Authorization Server, handing it the device token. The Authorization Server validates that the user ID is still allowed to login by the customer, and if so returns an access token for use during this application session.
  • The application calls the Adobe Licensing Server, handing it the access token and the same computer data as used in call #2, and requesting a license for the identified user to use the application.
  • The Adobe Licensing Server verifies with the Adobe Authorization Server that this user currently authorized to use the application.
  • The Adobe Licensing Server returns a signed license to the application, authorizing the user to use the application for the remainder of the customer’s paid license period.
  • The Application saves the license in the OS user credential store.

At this point, if the computer were to go offline, future launches of the application would be able to find the cached device token and the cached application license in the OS User Credential Store, and would permit the user to use the application. Whenever the computer gets back online, the application would immediately repeat the licensing phase to confirm that the user is still allowed to log in and to use the application.

Adobe Licensing in Secure Environments – Feature Restricted Licensing

In the Feature Restricted Licensing (FRL) case, each computer which is to be licensed for a given application must, in addition to having the applications installed, be preconfigured. Computers are preconfigured by installing a “licensing package” generated by an administrator on the Adobe Admin Console. This licensing package determines which applications can be licensed, whether or a not a licensing server should be contacted (and at what network address), and (if so) how often the computer should attempt to contact the licensing server to re-validate any existing cached license file. This licensing package can, optionally, contain all of the applications for which an organization has purchased licenses, making it simple for an administrator to preconfigure the computer with both the license and the applications at the same time.

A licensing package is simply an installer which is executed on a computer. Customers who do networkbased, administrative installation of application packages (using a third-party provider such as SCCM or JAMF) can continue to deploy licensing packages in the same way. When it is installed, the license package puts the licensing information into one or more files in the all-users area of the OS. This licensing information is signed with Adobe licensing keys to establish its authenticity and ensure data integrity.

When an application launches on a computer with an FRL licensing package, it will see the installed licensing information, and then look for a previously cached license from a prior run. If there is none, or if the installed licensing information says that the license should be re-validated with the licensing server, then the application will follow the directions included in the installed licensing information in order to retrieve a new license. After retrieval and verification, the application caches the retrieved license in the per-OS-user credential store, where it can be found on a later launch. Exactly how the license is requested and retrieved depends on the licensing method specified in the installed licensing information. There are three such methods; each is described below.

FRL – Connected

This is the simplest licensing method for customers to deploy. The computers must have access to the internet at least once, but that access can be controlled by a firewall device that intercepts and unpacks all Adobe network traffic to verify its content and ensure that:

  • no unauthorized data is sent outside the internal network;
  • all transmitted data is sealed inside of an encrypted tunnel; and
  • the endpoint of every transmission is an authorized, customer-specific Adobe licensing server with a fixed network address and a publicly signed, non-revoked SSL certificate.

In this method, each application which is launched on a customer computer creates a license request containing only:

  • an Adobe-generated package ID which identifies the installed licensing information;
  • an Adobe-generated device ID which is a SHA-256 hash of various computer characteristics, such as motherboard serial number and/or boot disk serial number;

The application then sends this request, using the https protocol, through the customer’s firewall device (see above) to a customer-specific Adobe licensing server on the internet. When the Adobe server responds, it provides an Adobe-signed license specific to the computer making the request. The application is then licensed on that computer for the duration of the customers contract.

FRL – LAN

This method is for customers who maintain secure networks which are not connected to the internet. In this case, the customer must deploy one or more instances of an internal licensing server (an Adobeprovided Java Application with a browser-based user interface that can run on Windows Server and Cent OS operating systems) and customer computers must be able to contact these server instances to receive their licenses. In addition, the customer must do a periodic authorization of each server instance (at least one per year) so as to enable the server to issue licenses and to reconcile the licenses issued by all the customer’s internal servers with the provisions of the customer’s contract.

To do the initial authorization of an internal licensing server, the customer first deploys the server application and then downloads (via its web interface) an authorization file, which is an Adobe-signed, human-readable, plain text file that contains a UUID that identifies the server instance. (No issued license information is in this first report, since the instance hasn’t issued any licenses at this time.) That authorization file is then taken outside the secure network so that it can be uploaded to the Adobe Admin Console. When uploading this initial report, the customer admin also defines parameters needed for the server’s operation:

  • how this server can be reached over the customer’s internal network (DNS & Port Number);
  • which products (of those on the contract) this server is allowed to issue licenses for;
  • If this server should have a Hard or Soft license allocation quota;
  • how long a computer can run without being able to re-validate its license with this server (The maximum duration will result in the client being able to remain offline for the duration of the contract).

Based on this information, along with a customer-defined “server name” for the server instance, Adobe generates a signed, plain text authorization file for the server with server-specific certificates that the instance can use to generate product licenses. The customer takes this authorization file into his internal network and uploads it (via the web interface) to the server instance. At that point the instance is ready to license computers on the customer network.

Once a customer administrator has defined one or more licensing internal licensing server instances, he is ready to create licensing packages (with or without the licensed applications) via the Adobe Admin Console. For each such licensing package, the admin specifies which internal server instance(s) the licensed applications will attempt to contact with their license requests. These packages are then downloaded and transported to the internal network, where they are deployed to computers.

In this method, the contents of each license request generated by an application at launch is the same as described above under FRL Connected, but the license request is directed to the internal license server instance named in the licensing package. That internal server logs the request into a server-specific database and then responds with an Adobe-authorized, signed license specific to that computer. The application in use is then licensed on that computer for the duration of the customers contract with Adobe.

At any time, the customer can use the web-based interface on an internal licensing server instance to download a CSV file. This file is only for the customers benefit and is not submitted to Adobe. This file contains all the license request information from computers that the server has licensed, including:

  • the device ID
  • internal reporting info such as hostname, OS type, OS version
  • the date the computer was first licensed; and
  • the most recent date the computer refreshed its existing license.

Each time a licensing server is re-authorized, it is given new certificates by Adobe that allow it to operate for another year (up to the end of the customers’ contract).

Licensing Server Requirements

You will need an SSL certificate (either purchased or self-signed) as a prerequisite for setting up the server.

System requirements

  • Java SE Runtime Environment 8
  • Windows Server 2012, 2016 (MVP), or 2019 OR CentOS 7 (Physical or Virtual machines are supported)
  • Hard disk space: 1000 end-user licenses require approximately 200 KB of Hard disk space

Browsers supported for the LAN Server Management Console

  • Google Chrome
  • Mozilla Firefox

Internet connectivity requirements

  • We do not expect the server machine that is issuing licenses to end-user machines or the enduser machines to ever be connected to the Internet.
  • The Authorization of the server will happen offline and using a manual file transfer.
  • When setting up the licensing server, all files uploaded to or download from the Adobe servers are human- readable.

Prerequisites

  • SSL certificate. Your internal licensing server communicates using HTTP over SSL. This ensures a secure network communication between the server and end-user machines. As a prerequisite to the licensing server setup, an SSL certificate (either from a service provider or self-signed) must be set up on the licensing server machine. Note: If you are using a self-signed SSL certificate, this certificate must also be installed on each end-user machine. Also, setting up the server requires you to run PowerShell scripts. To run the scripts, you are required to install the self- signed certificate on the Windows Certificate store.
  • KeyStore (JKS) file. To set up an SSL certificate, you will need to create a KeyStore file on your licensing server.

FRL – Isolated

This method is for customers who have computers that are not on any network, and thus must have their licenses directly installed from media along with their licensing package and applications. It requires that the customer run an Adobe-provided executable, called the Licensing Toolkit, on each isolated computer to be licensed. This tool provides a CRC32 checksum of the computer’s machine ID that Adobe uses to issue the computer’s license. The Isolated licensing method is suitable both for bulk licensing of many such computers (e.g., when they are first prepared for use), and for computer-by-computer licensing of isolated computers after they have been placed into their final (isolated) environment. The steps in each case are slightly different; we shall describe Bulk Licensing first and then Individual Licensing second.

FRL Isolated – Bulk Licensing

When a customer has many isolated computers that need to be licensed, it is easiest to first census all the computers before creating their licensing (and application) package. By using the Bulk Licensing workflow at licensing package creation time, the customer can specify all the target machine IDs at once. The resulting package can be burned to a single piece of media which is then installed on all the computers; this package will contain the licensing information, the applications, and each computer’s specific license. Diagram 3 depicts this process.

Adobe FRL Isolated Bulk Licensing workflow schematic
Diagram 3 – Feature Restricted Licensing, Bulk Licensing workflow steps.

The details of the steps in the FRL Isolated – Bulk Licensing process are:

  • Download the Licensing Toolkit (a command-line executable) from the Admin console.
  • Run the Licensing Toolkit on each of the computers to be licensed. On each computer, the Licensing Toolkit will output the machine ID as an 18-digit alphanumeric string (three groups of six characters each, separated by hyphens).
  • Collect the machine IDs into a CSV file. (Note: if the computers are not isolated when this process is run, an admin you can use standard network-based tools to run the Census Tool and collect the results without physically visiting each computer.)
  • Upload the CSV file to the Admin Console in the process of creating the licensing (and application) package.
  • Download the resulting package.
  • Install it on each computer.

At this point all the computers are fully licensed for the duration of the customer’s paid contract period.

FRL Isolated – Individual Licensing

When a customer needs to replace an isolated computer in the field, it will likely not be convenient for him to generate a new piece of media containing the licensing package, applications, and license data for that single computer. In this case, he can reuse a prior-created Isolated licensing (and application) package on the replacement computer. Diagram 4 shows this process.

Adobe FRL Isolated Individual Licensing workflow schematic
Diagram 4 – Feature Restricted Licensing, Individual Licensing workflow steps.

The details of the steps in the FRL Isolated – Individual Licensing process are:

  • A computer administrator local to the computer installs the prior-created Isolated licensing (and application) package on the computer.
  • The computer administrator then runs the Licensing Toolkit (which will have been installed by the package as well). The Census Tool will produce an 18-character Reactivation Code (three groups of six characters each).
  • The computer administrator reports the Reactivation Code to a customer IT administrator who has network access.
  • The IT administrator enters the Reactivation Code into the Adobe Admin Console.
  • The IT administrator receives a 36-character Reactivation Response Code (six groups of six characters each, separated by hyphens), and relays it to the computer administrator.
  • The computer administrator runs the Census Tool again, giving it the Reactivation Response Code. The Census Tool uses this code to license the computer.

At this point the replacement computer is licensed for the duration of the customer’s paid contract period.