PDF security: Adobe LiveCycle Policy Server

Dan Shea Planet PDF Managing Editor

September 07, 2005

In past weeks, I've posted a general Introduction to PDF security, an overview of Acrobat 7's eEnvelopes and security policies and covered the basics of digital signatures. While it's not strictly necessary to read those articles first -- particularly if you already have some familiarity with PDF security -- it is helpful, as they provide a solid introduction to PDF security concepts.

This installment provides a little more information on Adobe's server-based security solution. As its name implies, Adobe LiveCycle Policy Server (ALPS) allows for the creation, administration, application and authentication of security policies. For the purposes of this article, we will concern ourselves primarily with the capabilities and uses of Policy Server rather than running through in-depth instructions, which are more the realm of tutorials or product help files.

For the uninitiated, a security policy is the name given by Adobe to a configurable, re-usable profile that defines security settings that can be applied to a document. They serve to define the usage rights of a document. For example, security policies define who can open, print, edit or fill-out the PDF file.

Once a security policy is applied to a document, it becomes a part of it, meaning that the document will retain its security no matter how many times it is passed on or distributed. At this point, it may seem that the term "security policy" is simply a new name for document security settings. There are a few key differences here: firstly, security policies can be saved and re-used; secondly, they can be connected to ALPS.

Adobe LiveCycle Policy Server can be used to create new security policies or apply existing ones, but perhaps its most useful function is its ability to act as a web-based authentication engine. Documents configured to communicate with the Policy Server-enabled server in this way can have their permissions managed dynamically by the document provider.

The way it works is this: before a recipient can access the document, Adobe LiveCycle Policy Server first authenticates the recipient's identity against credentials stored in the organization's LDAP directory. Then, using Acrobat or the freely available Adobe Reader software, they may use the document according to the controls established in the policy.

This also means that permission for a given document can be revoked simply by updating the policy on the server. This solves the old problem of revoking the security access of ex-employees or those that change their role within an organization. For offline access, it's also possible to set document expiry dates, where users are allowed time-limited or subscription-based access to a given PDF document or set or documents. This forces recipients who desire continued use of protected content to request additional offline access from the document provider once their expiry dates have been reached. This time-limiting feature can also be very useful when it's crucial to have current information, as documents can be set to expire once their content becomes obsolete.

Keeping track of documents is also an important piece of the puzzle, and ALPS also supports an automated document auditing feature. This can be used to track the recipient's use of a protected document, and monitors what happened to it and when.

If you are interested in finding out more about Adobe Policy Server, there are various materials available at the Adobe website.

That's the end of part four in my series on PDF security. In future articles, I'll address redaction and 3rd party tools. If you're not familiar with those terms, you may just want to read those columns to find out more!