Hi, everyone.  A couple weeks ago, a post on the SharePoint Team Blog mentioned a new feature in Windows SharePoint Services V3: server-side Information Rights Management (IRM). There has been a lot of buzz about the feature since then, so I figured I should talk a little more about it here. If you don’t know much about IRM in the Office client, check out this article on Office 2003’s IRM capabilities. Basically, IRM allows individuals to put a customized digital envelope around content. This helps prevent sensitive information from being printed, forwarded, or copied by unauthorized people. After permission for a document has been restricted by using IRM, the access and usage restrictions are enforced no matter where the document is located, because the permissions are stored in the document itself. We call this, “persistent security.”

 

The impetus for integrating IRM with SharePoint came from many sources, but one piece of customer feedback stood out when we started planning for the 2007 release.  When we talked with customers about IRM in Office 2003, we often heard something like, “IRM is great – it helps my employees manage sensitive documents and comply with policy. However, the average knowledge worker usually doesn’t know or understand the corporate policies on a document. Is there any way we can automate the rights management process and centralize where corporate policies are specified?”

 

By piggybacking off the permission policies in a corporation’s collaboration server (aka SharePoint), we’re enabling this idea of “centralized information rights management.” Here’s how it works: Once IRM capabilities are enabled on a SharePoint farm, list administrators can specify IRM settings on each list, document library, or InfoPath form library using the following Information Rights Management Settings page:

 

As you can see, a list administrator can specify a bunch of IRM settings on the document library.

 

When a user downloads a document from an IRM-enabled library or views the contents of a document inside her browser, SharePoint creates a rights managed version of the file and gives this copy of the document to the downloader. The downloader’s IRM rights to the file match her role on the SharePoint library. So, if the downloader only has the Viewer role on the document in SharePoint, she’ll have the View right in the downloaded copy. In essence, IRM rights are “sticky” or persistent SharePoint permissions that stay with the document after it has left the server.

 

The downloader is the only user with access to the downloaded copy of the file, so you can think of this copy as a temporary permission contract between the downloader and the server. This helps ensure that SharePoint is the central collaboration point for the document.

 

When the downloader uploads the file back to the library, rights management is removed and the document is stored unencrypted on the server. This allows the content in rights managed libraries to be searched and avoids the problems associated with long term storage of encrypted content. Don't worry though; SharePoint ensures that search results are properly filtered so that users can only see items that they have permissions to at least view.

 

Server-side IRM, just like IRM in the Office client, is file format specific. Hence, SharePoint needs to have specific knowledge of a file format in order to apply IRM to the files of that format. Out of the box, Microsoft Office SharePoint Server (MOSS) 2007 ships with “protectors” for Word, Excel, and PowerPoint documents – both the Office 97-2003 file formats and the new Open XML formats. In addition, MOSS 2007 can apply IRM to InfoPath forms and templates as well as XPS documents. Because SharePoint leverages Windows Rights Management Services to these files, they can be opened natively in the Office client – just like any other IRM protected document.

 

On each document library, a list administrator can specify what to do with files that it cannot protect with IRM. For instance, the administrator can check the “Do not allow users to upload documents that do not support IRM” option, so SharePoint will prevent files that it cannot protect with IRM from being uploaded into the document library.

 

So, that’s the high level overview of the IRM framework in SharePoint. What I’m most excited about, however, is how our customers and partners implement and extend the IRM capabilities. We offer a pluggable infrastructure, so partners can write custom protectors that can rights manage other file types besides Office documents. Partners can even use a third-party rights management platform instead of Windows RMS. I also expect SharePoint IRM to be combined with other features in some very useful ways. For instance, customers can use group policies to restrict the available locations that appear in an Office client product’s Save As dialog. By showing only IRM-enabled document libraries in this dialog, corporations can much more consistently and reliably enforce the appropriate information rights management policies on all documents within particular workgroups (such as Legal or R&D) where there’s a high percentage of sensitive information that needs to be protected.

 

Thanks for reading and comment away if you have any questions!

 

 

Adam Harmetz

Program Manager