2.1.2.2 Client-to-Server and Server-to-Server Functionality
RMS protocols have two main sets of services, the client-to-server services and the server-to-server services. The client-to-server services are the individual interfaces that RMS client applications call to perform RMS tasks such as bootstrapping, retrieving templates, publishing content, and licensing content. The server-to-server services are the tasks that are performed to determine group membership of users across complex network directories. The RMS protocols also have an ISV extension interface that can be used to enable RMS in applications that do not necessarily use the RMS client services.
The following diagram shows the structure of the services in RMS.

Figure 4: RMS white box diagram
Client-to-server interfaces
Certification service: The certification service provides RMS client applications with the ability to bootstrap and receive the necessary certificates to participate as a consumer in RMS. The certification service is the interface that RMS client applications use in the use case "Bootstrap RMS Client - RMS Client Application" described in section 2.5.4.2.
Certify: As part of the bootstrapping process, an RMS client makes a request to the Certify web request. This request includes the client's security processor certificate (SPC); authentication is also performed as part of this request. The server validates the data that it receives and, if it is authorized, returns the user's RAC. Full details of the Certification Service schema can be found in [MS-RMPR] section 3.3. Details of the Certify request can be found in [MS-RMPR] section 3.3.4.1.
Licensing service: The licensing web service provides two functions, issuing use licenses (ULs) for protected content and providing rights policy templates to client applications that request them. Full details of the Licensing Service schema can be found in [MS-RMPR] section 3.4.
AcquireLicense: To consume protected content, the client acquires a use license, which gives the user access to the content and includes the key to decrypt the content and the usage policies for the content. To acquire the use license, the client uses the AcquireLicense request, sending the RAC, publishing license (PL), and application data to the RMS server. After validating the RAC and the PL in the request, the server returns the use license for the content. Details of the AcquireLicense request can be found in [MS-RMPR] section 3.4.4.1.
AcquireTemplateInformation: To retrieve rights policy templates, the client first makes a request to the AcquireTemplateInformation request. The server returns information about the available templates in the form of a list of globally unique identifiers (GUIDs) and hashes corresponding to the server templates. Details of the AcquireTemplateInformation request can be found in [MS-RMPR] section 3.4.4.2.
AcquireTemplates: After receiving the list of templates, the client determines which templates to download from the server. The client uses the AcquireTemplates request with a list of rights policy template GUIDs and request templates corresponding to these GUIDs. Upon receiving the request, the server returns the templates to the client. Details of the AcquireTemplates request can be found in [MS-RMPR] section 3.4.4.3.
Publishing service: The publishing service has two functions, to sign publishing licenses (PLs), which are generated during online publishing, and to provide client licensor certificate (CLC) chains, which are used in offline publishing. The publishing service provides RMS client applications with the ability to participate as a publisher in RMS. Full details of the publishing service schema can be found in [MS-RMPR] section 3.5.
AcquireIssuanceLicense: During online publishing, the RMS client application gets the server licensor certificate (SLC) chain from the server (see details on the GetLicensorCertificate operation in section 3.3.2.1), generates a symmetric content key, and generates usage restrictions. The RMS client application generates a publishing license (PL), which includes the content key and use restrictions. The content key and use restrictions are encrypted with the server's public key (from the SLC).
-
In online publishing, after the PL is created, it is signed by the server. The AcquireIssuanceLicense request is used to sign a PL during online publishing. The RMS client application makes an AcquireIssuanceLicense request to the server with the unsigned PL. The server signs the body of the PL and returns it to the RMS client application. Details of the AcquireIssuanceLicense request can be found in [MS-RMPR] section 3.5.4.1.
GetClientLicensorCert: During offline publishing, the RMS client application uses the CLC to publish content without contacting the RMS server. The CLC contains the server's public key, which is used to encrypt the content key and use restrictions in the PL. The CLC private key is used to sign the body of the PL.
-
The GetClientLicensorCert request is used to obtain the CLC for the user. The user needs to have a RAC and an SPC to use this method. In the GetClientLicensorCert request, the client submits a RAC chain and requests a CLC chain. When the server receives the request, it performs a signature validation on the RAC chain and verifies that it trusts the RAC. The server generates a CLC, which contains a unique asymmetric key pair. The server encrypts the CLC private key with the public key of the RAC, so that the RAC and the SPC are required to access the signing key in the CLC. Details of the GetClientLicensorCert request can be found in [MS-RMPR] section 3.5.4.2.
Server service: The server service has two purposes, to provide the service location for users and to provide the SLC for use in online publishing. Full details of the server service schema can be found in [MS-RMPR] section 3.7.
FindServiceLocationsForUser: Depending on the RMS server configuration, different servers can be used for different functions for a given user. The client uses the FindServiceLocationsForUser request to discover the appropriate server for various services for a given user. The server uses the GetAuthenticatedAccount abstract interface to determine the authenticated domain account. When servicing FindServiceLocationsForUser requests, Windows implementations of the RMS server use the GetAuthenticatedAccount abstract interface to retrieve the domain account, which is authenticated by using the NT LAN Manager (NTLM) Authentication Protocol through Microsoft Internet Information Services (IIS), as described in [MS-NTHT]. The SOAP request does not encapsulate the authentication.
-
When the RMS client application makes a FindServiceLocationsForUser request, it includes a service type (for example, "user certification") and requests its location. Given the authenticated domain account and the requested server type, the server determines the service location by using the GetDirectoryForAccount and GetServiceLocationForDirectory abstract interfaces and returns the URL to the RMS client application. Details of the FindServiceLocationsForUser request can be found in [MS-RMPR] section 3.7.4.2.
GetLicensorCertificate: During online publishing, the RMS client application retrieves the SLC from the RMS server. The SLC public key is used to encrypt the symmetric content key and use restrictions in the PL.
-
The RMS client application makes a GetLicensorCertificate request to the server; no information is sent in the request. Upon receiving the request, the server returns its SLC chain. Details of the GetLicensorCertificate request can be found in [MS-RMPR] section 3.7.4.1.
Server-to-server interfaces
Find Service Locations: RMS servers use the Find Service Locations interface of the Rights Management Services (RMS): Server-to-Server Protocol [MS-RMPR] to find the URLs for specific services that are provided by other RMS servers. This communication can be useful in two scenarios:
Finding the appropriate URLs for a client to use for bootstrapping.
Finding the Group Expansion interface on a remote server before making a group expansion request across forests.
-
Clients contact the server for a bootstrapping process to begin functioning in RMS. This bootstrapping process is defined in the RMS: Client-to-Server Protocol [MS-RMPR]. To bootstrap a specific user, the RMS server authenticates that user and determines the user's email address by checking the directory. If the user's account resides in a separate directory (forest) that the RMS server cannot access, it cannot successfully bootstrap the user. A client starts the bootstrapping process by making a request for service locations to a specific RMS server. If that RMS server is not the appropriate server to bootstrap the client, the server can use the Find Service Locations interface to find the URLs on the appropriate server and return them to the client.
-
The Find Service Locations interface uses a SOAP-based protocol over HTTP. It exposes one request/response method: FindServiceLocations.
Sub-Enrollment: RMS servers use the Sub-Enrollment interface of the RMS: Server-to-Server Protocol to bootstrap subordinate RMS servers.
-
As the preceding diagram shows, an RMS server can be deployed as a subordinate server to another RMS server. A root RMS server grants a subordinate RMS server the right to perform only licensing tasks by issuing a subordinate server licensor certificate (SLC) from its own SLC. For a subordinate RMS server, this process replaces the standard RMS server bootstrapping process defined in [MS-RMPR] section 3.1.3.
-
The Sub-Enrollment interface uses a SOAP-based protocol over HTTP. It exposes one request/response method: SubEnroll.
Get Licensor Certificate: RMS servers use the Get Licensor Certificate interface of the RMS: Server-to-Server Protocol to establish trust from a root server to a subordinate server.
-
When a subordinate RMS server is deployed, it needs to trust identities that are issued by the root RMS server. This requirement is accomplished by trusting certificates that were issued by the root RMS server by trusting the root RMS server's public key. The subordinate server can use the Get Licensor Certificate interface to retrieve the SLC of the main server that contains the appropriate public key.
-
The Get Licensor Certificate interface uses a SOAP-based protocol over HTTP. It exposes one request/response method: GetLicensorCertificate.
Group Expansion over SOAP: RMS servers use the Group Expansion over SOAP interface of the RMS: Server-to-Server Protocol to determine group membership of authorized users across complex network directories.
-
Access policy on RMS-protected content can specify individual users and distribution groups. When a consumer contacts the RMS server for authorization to access protected content, the server might have to check the directory to determine whether that user is a member of a group with rights to use the content. If that group exists in a separate directory (forest) to which the RMS server does not have access, the RMS server contacts another server that does have access to that directory and that can provide information about the group membership. This server-to-server communication can use either the Group Expansion over SOAP interface or the Binary Group Expansion interface.
-
The Group Expansion over SOAP interface exposes one request/response method: IsPrincipalMemberOf.
Binary Group Expansion: The Binary Group Expansion interface performs the same function as the Group Expansion over SOAP interface; however, it does so by using a binary-formatted message that is sent over HTTP. It exposes one request/response method: IsPrincipalMemberOf. This interface is not available in RMS: Server-to-Server Protocol version 2.0. For more details, see [MS-RMPRS] section 3.5.
ISV extension interfaces
Decommission server: If an organization decides to stop using RMS entirely and to remove its deployment, it needs to remove RMS protection from content. One method is to have users with owner rights to each piece of content remove the protection. Realistically, however, it is often impractical to find these users because they might no longer belong to the organization in question. Another approach is to use the Decommissioning interface to extract the content key from a PL and return it so that it can then be used to decrypt the content. Because each protected document has a PL, and each PL has its own content key, this process needs to be repeated for each protected document that will have its protection removed.
-
When servicing the request, the RMS server does not verify that the requestor is supposed to be granted access to the content as indicated in the PL. Instead, the RMS server returns the content key to any requestor. As a result, the Decommissioning interface is disabled for normal operation by default. The interface exposes one request/response method to support decommissioning: AcquireContentKey.
Precertification: When protected content is sent to recipients, each recipient acquires a use license that grants access to the content. The use license describes the usage policy for that user with that content and encrypts the content key to the user's public key. This process and protocol is specified in the Rights Management Services (RMS): Client-to-Server Protocol [MS-RMPR].
-
As an optimization, the use license for a recipient can be generated in advance and be made available with the content at the time the recipient attempts to access it. The use license can be requested on behalf of the recipient by either the sender or a server application that might be involved in delivering the content to the recipient. This use license allows the recipient to access the content as soon as it is delivered without having to contact the RMS server, presuming that the recipient has already been bootstrapped.
-
In order to acquire a license on behalf of a recipient user, a requestor retrieves the public part of the recipient's RAC by using the Precertification interface, and then requests a use license from the RMS server by using the RMS: Client-to-Server Protocol, as specified in [MS-RMPR]. The Precertification interface exposes one request/response method to enable precertification: Precertify.
Republishing: After protected content is published, it might become necessary to alter the set of rights that are granted to users in the original PL. The EditIssuanceLicense operation ([MS-RMSI] section 3.4.4.1) allows a client to submit the original signed PL and an unsigned PL that contains the altered rights. The RMS server responds with a new, signed PL that contains the same content key as the original PL.
-
PLs are required to permit republishing, as specified in [MS-RMSI] section 3.4.4.1. In addition, access to this service is typically restricted to computers or users that are trusted by the administrator. The Republishing interface exposes one request and response message to enable republishing via the EditIssuanceLicense operation.
Prelicensing: When using the Precertification interface, the application is required to contact a server that is capable of issuing a RAC for a specific recipient. In an environment with multiple certification services, an application might require an application-specific configuration to determine which certification service to use for each user. If multiple applications prelicense content, an administrator might have to configure this data in independent ways.
-
The Prelicensing interface shifts this responsibility to the RMS server. The application can specify a list of recipients by email address and provide a PL. The RMS server determines the public key for each user and issues a use license for each recipient. The use license is based on the rights that are granted in the PL. The RMS server itself can use the Precertification interface of another server to retrieve a public key for a user when the user's key resides on that server. The Prelicensing interface exposes one request/response message to enable prelicensing via the AcquirePreLicense operation ([MS-RMSI] section 3.5.4.1).