Export (0) Print
Expand All

11.2 Rights Management Services Functionality

Implementation of the Rights Management Services allows for the creation, access, and consumption of protected content. When this functionality has been implemented, the creator of a document can limit and control the use of the protected content. This can be accomplished from within the application that creates the protected content.

Examples that illustrate the interaction of some of the protocols are provided in two sample configurations in section 11.4.

Access to protected content is under the central control of the RMS server. This server-based control allows the implementation to use a single authentication mechanism for the purpose of granting access rights to protected content.

The server is required to undergo a one-time bootstrapping process to begin functioning in the RMS system. In RMS 1.0, RMS 1.0 SP1, and RMS 1.0 SP2, this operation involves contacting the cloud service. In RMS 2.0, this operation is done entirely offline. The creator and consumer contact the server for a one-time bootstrapping process to function in the RMS system.

The consumer, upon receiving the document from the creator and opening it, supplies the server with the PL and the RMS account certificate (RAC) that was acquired during bootstrapping. If the consumer is allowed access according to the access policy in the PL, the server issues the consumer a use license (UL) that specifies the access policy for the consumer and binds the content decryption key to the consumer's RAC. The RAC key is encrypted by the key of a trusted software module called the security processor. When the consumer attempts to access the document, the security processor decides whether the requesting application on the consumer machine is capable of enforcing the access policy. If so, it supplies plain text of the document to the application along with the policy that the application is to enforce.

Consumption of the protected content means that a client received the proper licenses issued, via the RMS server, to allow access to the protected content, under the terms and restrictions of the license that the server granted and that the document creator requested.

Regardless of functionality, the RMS system components comprise four active entities: the creator, the consumer, the server, and the cloud service.

  • Creator: The creator is the entity that builds the document to be protected. After the document has been created, the creator can then choose an access policy for the document or make use of a pre-existing rights policy template. After encrypting the document, the creator can then make use of a publishing license to bind the selected access policy to the document.

  • Consumer: After consumers have received a protected document, they will attempt to open it. The consumer system contacts the server, and the server makes use of the publishing license and RMS account certificate (RAC) already acquired. After the server decides that access is permitted, it issues a use license to the client that specifies the access policy for the client and binds the encryption key to the consumer's RAC.

  • Server: The server controls the access to the protected content. It does this by issuing signed certificates and keys. The server is the sole authority for the evaluation of client identity and issues authorizations based on client-provided identity credentials.

  • Cloud: The Cloud service contains the Enrollment service, which allows clients to get the credentials necessary for obtaining the rights to digitally protected content. The Cloud service also contains the Activation service necessary for RMS clients earlier than version 2.0.

A client can play the role of a creator, a consumer, or both, depending on the implementation. The client is responsible for requesting certificates, licenses, and policies from the server. It is also responsible for enforcing authorization policies as they apply to protected information and encrypting or decrypting content as appropriate. The RMSv2 client in Windows Server 2008 operating system and Windows Vista operating system with Service Pack 1 (SP1) also has the capability to fetch rights policy templates from an RMSv2 server.


Figure 73: High-level overview of the RMS system

The following are some of the ways that implementers can integrate this functionality into their services.

This baseline RMS scenario involves three actors: the publisher/author, the consumer/recipient, and the RMS server. The publisher and consumer are both roles of the RMS client. For this scenario, we assume that the publisher, consumer, and server are all bootstrapped (that is, started automatically.)

  1. A publisher creates content in an RMS-enabled application. The publisher protects the content and applies a usage policy that specifies recipients by their email addresses. Recipients can be individual users or distribution groups in a directory. The publisher then specifies what access rights are to be granted to each recipient: such as read, edit, and print. The publisher also specifies any conditions on those rights: for example, expiry after a period of time. This protection step calls in to the RMS client to encrypt the file and create the policy. The policy lives in a Publishing License (PL). The PL describes the access policy and contains the content key; all of this data is encrypted with the RMS server's public key.

  2. The publisher sends the content to the recipient using any mechanism, such as USB flash drive, email, or file share. RMS does not do the actual distribution of the content.

  3. The recipient receives the file and needs to access it. When the recipient tries to open the file in an RMS-enabled application, the application realizes that the file is protected and that the user does not yet have an authorization token [Use License (UL)] for the content.

  4. The application calls into the RMS client to acquire a UL. The client makes an AcquireLicense request to the RMS server. (This is the first and only client-server interaction in this scenario.) The AcquireLicense request submits the PL, along with the user's RAC to the server. The RAC is the user's encryption certificate. The client may discover the RMS server location through Active Directory, existing client configuration data, or from the DISTRIBUTIONPOINT element in an existing license.

  5. The RMS server checks the signatures of the PL and the RAC to determine whether they can be trusted.

  6. The RMS server decrypts the policy data and content key from the PL and checks to see whether any of the principals named in the PL match the principal named in the RAC. This check may involve expanding groups by contacting a directory.

  7. If a match is found, the RMS server determines the rights that are to be granted to the user, along with any conditions on those rights. It also encrypts the content key with the user's RAC public key. This authorization data and encrypted content key are packaged in a UL and sent to the client in the response to the request.

  8. With the UL, the recipient now has the data needed to consume the content. The application passes the RAC and UL into the RMS client so that the RMS client can decrypt the content. The RMS client evaluates what rights are to be granted along with any conditions on those rights, and then uses the security processor to decrypt the RAC private key. The private key is then used to decrypt the content key from the UL, which is then used to decrypt the content.

© 2014 Microsoft