Share via


Publishing Content with Web Applications

Most Active Directory Rights Management Services (AD RMS) SDK publishing scenarios use the following actions.

Action Description
Encryption Encrypting content by using an encryption technology such as the CryptoAPI functions or System.Security.Cryptography classes.
Issuance License Creation Creating an issuance license for the content that specifies who can be permitted what uses of the content, how long these rights exist, and other requirements. This license, which is the only one an application will directly create, is called an issuance license.
Document and License Delivery Putting the issuance license and content into a format that a consuming application can understand (compound files in the sample application and protected Web page scenarios).

These core actions are explained in greater detail below.

Encryption

An application that consumes AD RMS-protected content uses the AD RMS client to decrypt the content. Therefore, you can only encrypt content by using a cryptographic algorithm that is supported by the AD RMS client. Currently, AD RMS uses the AES encryption algorithm. You can either have AD RMS encrypt the content or encrypt the content yourself using the CryptoAPI with AES. For more information about using AD RMS to encrypt content, see Encrypting Content by Using AD RMS Functions. For more information about using the CryptoAPI to encrypt content, see Encrypting Content by Using CryptoAPI Functions. The only encryption mode that is supported is ECB.

Issuance License Creation

Your application will create an issuance license that specifies users, rights, and validity periods for these rights (for periods that are accurate to the second), use conditions, custom name-value pairs, and other information for a piece of content. You can retrieve an issuance license by calling the AcquireIssuanceLicense SOAP Web method. To learn more about issuance licenses and what they can specify, read Creating an Issuance License.

An issuance license assigns specific rights to specific people (or groups of people, or all users). There are only three predefined rights (OWNER, EDIT, and VIEWRIGHTSDATA); all others are application-defined. Therefore, the issuance license creator must know the exact list of rights that the consuming application supports. So, for example, you must know whether to create a right called PLAY_ONCE, SINGLEPLAY, or PLAY, depending on the specifications of the consuming application. For more information, see Interpreting XrML Rights.

Your application will deal with two kinds of licenses: issuance licenses (described previously), and use licenses, which are used to actually consume content. An issuance license is submitted to a licensing service to obtain a use license, which is the issuance license pared down to include only information specific to one user (plus some other modifications).

Your application is only responsible for creating an issuance license; the end user can acquire their own use license by using your issuance license. However, you can acquire a use license for a user in advance, so the user can avoid an extra trip to a licensing service. This is done in the sample application by using the SOAP method AcquirePreLicense. The sample application performs this task, as described in Acquiring the Use License.

Document and License Delivery

The publishing or use license must be packaged with the content in exactly the format and location that the consuming application expects. Otherwise, the consuming application will not be able to process the license and decrypt the content correctly. Therefore, you must build the consuming application yourself, own the format of the secure document, or use an open format.

As an example, imagine an XYZ file format that holds a AD RMS-protected file. This XYZ format is specified as encrypted ASCII text, followed by an issuance license in Unicode format at the end, surrounded by a string of fifteen Unicode zeros. An application that can read a file named Myfile.xyz must understand this file format. You can either build this application yourself, or create protected files following this standard. This is where the Active Directory Rights Management Add-on for Internet Explorer comes in.

Active Directory Rights Management Add-on for Internet Explorer

As you can see, there are two important restrictions on consuming a protected document:

  • Your publishing application must know exactly what rights a consuming application can process.
  • Your publishing application must know exactly where, and in what format, to store the issuance license and content in a file.

If you have your own custom file format that can read AD RMS-protected content, or access to such a format, you can use that. If you do not, Microsoft provides the Active Directory Rights Management Add-on for Internet Explorer. This add-on can process and display AD RMS-protected documents. It uses an open file format (called a compound file) that stores an encrypted document, and publishing and use licenses in specified locations, and supports a published list of rights. To view this list of rights, and for more information about how the add-on uses compound files, see the documentation in the Rights-Managed HTML SDK.

See Also

Building a Protected Document Library
Building a Publishing Application Without Using a Lockbox
Compound Files
Interpreting XrML Rights

Send comments about this topic to Microsoft

Build date: 3/13/2008