IRM (Information Rights Management) in SharePoint

This is just a very brief review from my reading of a MS white paper coming with the ECM starter kit.

IRM allows you to have control over a document after it’s downloaded from SharePoint.

This is how is works:

• You need to install/configure IRM at server farm first
• You can configure the Doc Lib to use certain IRM policy (such as No Print, or downloaded copy expires after x days). This policy applies to whole doc lib and you can’t customized at folder level.
• Nothing important happens when you upload a file
• When a support file (you have to install the “protector” for this file type. MOSS 2007 has word, excel, and powerpoint covered) is being downloaded, WSS will encrypt it and send you back the encrypted version.
• You need a IRM-ready viewer to view these files (Office 2003 is fine), or you need to install necessary components for your viewer.
• Your local viewer need to connect to a “Windows Rights management Services” server to decrypt the file.

For Word, Excel, and PowerPoint files, meta data are not encrypted.

User permissions findings

• When adding user by assigning individual rights, if only give user/group “Limited Access”, user will not be able to see the homepage of the site. Need to give user ‘Full access’ to see the home page (WHY?).
• If complete disable user access to Shared Documents, user can’t load home page. (?)
• When directly give use access to a sub folder, that user will be added to the parent folders with ‘Limited Access’ – all the way to “Shared Documents”
• When we remove a user from a folder, it will removed from sub-folders even sub-folders already removed permission inheritance!
• When we add a user to a folder, this user will NOT be added to the sub-folders if the sub-folders have been removed permission inheritance, which makes sense. Also any permission role changes to the parent folder will NOT be populated to sub-folders if permission inheritance is already canceled.
• For user to upload file, user has to have at least ‘View’ access to the document library (root) itself. The actual folder to which user tries to upload file may or may not inherit permission from doc lib.
• For user to start a workflow (the default ones), user need ‘Edit’ access on Doc Lib root.

Webpart security

If the webpart need to access Sharepoint server info, there are 3 options when deploying the webpart in security context:

1. Deploy to GAC, and no other settings need to be changed. Downside: need to recycle application pool when upgrade; webpart will be available to all sites in same server.
2. Deploy to \Bin, and change trust level in web.config to at least WSS_Medium. Downside: this grant the whole ASP.NET application higher access rights. This is very convinient in development stage.
3. Deploy to \Bin, and change trust level in web.config to wss_custom, then change/add the config file in \Program Files\Common Files\Microsoft Shared\web server extensions\12\config. This is safer because it only grant access to specified webparts. Recommended for production environment.

In any case, the webpart need to be signed (obviously) and marked as ‘SafeControl’ in web.config file.

If the webpart doesn’t need to access server resource, only need to mark it as SafeControl in web.config and add this line:

[assembly: AllowPartiallyTrustedCallers]

to the source file.