Background

SimplyE for Academic requires document-level DRM (Digital Rights Management) for certain types of content, in addition to access control support for hosted content that does not restrict use on an individual basis..

Some vendors provide their content directly to the University LIbrary, with the expectation that the library will host that content and make it available only to authorized (logged in) users. While much of the content has no restrictions or DRM protection in terms of time-limited use or “expiration” requirements, some does. This requires that the files be protected from access by users who have not authenticated with the Circulation Manager AND additionally be managed on the apps via a DRM technology. For SimplyE, that technology will be Readium LCP, which is compatible with the Readium rendering engine used by SimplyE.

Readium LCP is a new passphrase-based rights management solution, with support for different business models, including library lending. This is a simple but reliable solution for distributing protected content, based on encryption algorithms (AES-256) and classical PKI (public key infrastructure) techniques.

• A general description and architecture of the solution can be found here: https://github.com/readium/readium-lcp-server/wiki#fetch-an-encrypted-publication
• The code repository and readme can be found here: https://github.com/readium/readium-lcp-server
• Sequence Diagrams of the LCP Work flow and Transactions are here: https://github.com/readium/readium-lcp-server/wiki/Sequence-diagrams

LCP Content Protection Workflow

Architecture

The LCP server is written in Go and the software is composed of three independent parts:

1. lcpencrypt - An encryption tool for content encryption. This command line utility can be included in any processing pipeline. 

   Info
   lcpencrypt is a tool written in Go and needs special treatment. Unfortunately, Readium doesn’t publish binaries and lcpencrypt has to be compiled from the source code which requires having Go SDK installed locally. Compilation of lcpencrypt is incorporated into circ-exec and circ-scripts Docker image build process as a separate stage.

   
   

2. lcpserver - A license server, which implements Readium Licensed Content Protection 1.0.  

3. lsdserver - A license status server, which implements Readium License Status Document 1.0

LCP documentation also mentions frontend - a testing front-end server, which mimics your own frontend platform (e.g. bookselling website), with a GUI and its own REST API. Its sole goal is to help you test the License and License Status servers. In the case of SimplyE role of the frontend is played by Circulation Manager.

The picture below shows the high-level architecture of the LCP setup:

Image Added

Image I. LCP Architecture

Repositories

Now, let’s define repositories - storages used in the LCP workflow:

• master_repository is a storage where the hosting provider stores files before encryption.

• intermediate_repository is a storage where lcpencrypt stores encrypted books and where lcpserver looks for them after receiving notification.

• encrypted_repository is a storage where the encrypted books files are stored after lcpserver uploaded them there. This is the S3 bucket that the Circulation Manager will distribute content from.

Let's see different ways to deploy those repositories.

Single EC2 instance

First, let’s see a setup involving the single EC2 instance where both circ-scripts and lcpserver containers are deployed. The picture below shows where different repositories located:

Image Added

Image I. Repositories (single EC2 instance)

• master_repository is a local directory which is mapped into circ-scripts Docker image using a bind mount (see bind mount I).

• intermediate_repository is also a local directory which is mapped into both circ-scripts and lcpserver Docker images using bind mounts or a shared Docker volume (see bind mount II).

• encrypted_repository is an S3 bucket.

Multiple EC2 instances

Now let’s how the architecture will change if we spread circ-scripts and lcpserver across different EC2 instances:

Image Added

Image III. Repositories (multiple EC2 instances)

• master_repository is an EFS directory which is mapped into circ-scripts Docker image using a bind mount (see bind mount I).

• intermediate_repository is an EFS directory too which is mapped into both circ-scripts and lcpserver Docker images using bind mounts or a shared Docker volume (see bind mount II and bind mount III).

• encrypted_repository is an S3 bucket.

Importing collections into Circulation Manager

Import process consists of the following steps:

1. The content provider hands off a collection with encrypted books, their covers and metadata in ONIX/MARC formats to the hosting provider (for example, Lyrasis).
2. The hosting provider stores the collection in master_repository.
3. The hosting provider starts the encryption process by calling bin/directory_impoprt script.
4. bin/directory_impoprt script parses the collection’s metadata and calls lcpencrypt tool to encrypt the books.
5. lcpencrypt encrypts the books and stores them in intermediate_repository.
6. Lcpencrypt notifies lcpserver (the LCP License server) about the encrypted books.
7. lcpserver generates licenses and uploads books to encrypted_repository.

The picture below illustrates all the steps of the import process:

Image Added

Image IV. Import workflow

Fulfilment workflow

The fulfilment workflow is depicted in the picture below:

Image Added

Image IV. Fulfilment workflow