MOSS2007&RMS技术验证方案的进展状况

    最近在做一个关于MOSS集成RMS的技术验证方案，在该技术验证方案中，客户方面的需求是要在Sharepoint2007上能够实现RMS提供的所有权限设置，包括读取、变更、完全控制。加上只读可复制、打印等RMS可以设置的权限项。并且这些权限项都能够在目录以及文件本身设置，不像目前Sharepoint 2007那样，打印这些配置要在文档库这层设置。
    譬如说，我在Sharepoint 2007的权限级别上定义读取、变更、完全控制、只读可复制、可打印这些权限选项，当我在Sharepoint上设置了某个目录、某个文档相应的权限，文档离开Sharepoint后就根据用户设置的权限设置相应的RMS权限。
    我拿到用户需求后，设定了几种可能的解决方案：
1、找出文档库是如何对文件设置IRM保护的，如果有可能，通过调整IRM保护属性，对每个文件、目录进行IRM属性设置，就有可能轻松解决问题。
2、查询所有EventHandler，如果有关于文件下载、文件转换事件的处理函数，则在处理函数中添加自己的处理，如更改用户权限，修改用户IL、EUL信息，使系统自动生成符合预期IRM保护文件。
3、查看SharePointSDK，寻找通过编程途径解决。自定义文件下拉菜单项替换系统的文件下载项，在文件转换前，生成IL、EUL相关信息，进行文件转换。
4、找出MOSS如何使用IRM设置，如果该功能所涉及到的程序集不太重要，则对程序集进行反编译，修改并替换系统原有的文档加保护行为。
5、使用ECM Services，自定义文档保护器Protector，在Protector中自主获取MOSS中保存的用户信息，和权限信息，自己动手，丰衣足食，生成IRM文件。该方案被认为是一定可行的，但却是最费时费力的方案，只有其他路都行不通后才予以考虑。

    拟定策略后，便开始按上述优先级开展行动。首先是测试方案一，依次测试SPWeb、SPSite、SPWebApplication、SPList、SPDocumentLibrary、SPListItem、SPFile等类中的各项可能属性，如Audit、Fields、File、Properties、ApplicationRightsMask、WebApplication.RightsMask、GlobalPermMask属性，搜寻未果后又查找命名空间Microsoft.Office.RecordsManagement.InformationPolicy下的所有类，按照SDK文档中所描述，IRM权限信息，保存在”Site Policy”中，经过依次测试站点中给个关键类的Policy，仍然未发现相关设置。最后祭出必杀技：反编译，通过查看irm.aspx文件，找到其实现类为：Microsoft.SharePoint.ApplicationPages.IrmListSettings，虽然该方法经过混淆，但依然可以看出调用过程，原来是对整个文档库设置IrmEnabled属性标识文档库是否受IRM保护，在根目录的属性中设置vti_irm_IrmPrint、vti_irm_IrmVBA、vti_irm_IrmOffline、vti_irm_IrmExpireDate等属性来保存其他IRM属性。了解该设置方式后，通过程序，在所有目录中进行相应设置。实测表明，该属性的读取，仅从文档库的RootFolder中读取，其他设置一概无效。方案一被推翻。
    之后对方案二、三、四分别进行测试，都被一一否决，原因是由于该IRM属性的使用模块为：STSWEL.DLL，该模块为SharePointService的最重要的基础模块之一，该模块为非托管模块，所有编程接口不对外公开，所以我们无法干涉其行为模式。
    目前，我们所剩下唯一可行的技术路线基本只有重做Protector一条，接管原有OFFICE文档的文档生成过程，收到传入的IL和EUL后丢弃不用，自己取出MOSS中内置的权限管理内容，生成自己的IL和EUL，存储于文件中，供用户下载使用。
    但实际操作中仍然遇到许多问题。
    首先是制作一个完全传统的Protector，收到授权证书和最终用户协议后，不加修改的把字符流传给RMS进行加密，打包后将对象句柄交还给调用者。测试TXT文件时，基本正常，TXT文件能够被正常加密、解密。用同样的方法测试DOC文件，也可以实现文件的加密和还原，但是，经过加密后的文件内容不能被WordApplication识别，打开失败。
也就是说接下来的工作重点要客服如下几个技术难点：
1、 加密后的文件必须被正常应用程序识别，该技术可以从两方面着手：
一种方式是更改加密方式，深入研究MOSS的加密方法，并与其保持一致，当文件下载到客户端后，能够直接被WinWord应用程序识别。
Moss中内置的文档保护器有如下三个：
FormIrmProtector，保护扩展名为XSN,XML的文件，实现文件为 Microsoft.Office.Irm.FormProtector.dll
MsoIrmProtector，保护文件 doc,dot,xls,xlt,xla,ppt,pot,pps，实现文件为Microsoft.Office.Irm.MsoProtector.dll
OfcIrmProtector，保护文件xps,docx,docm,dotx,dotm,xlsx,xlsm,xlsb,xltx,xltm,xlam,pptx,pptm,potx,potm,thmx,ppsx,ppsm实现文件为Microsoft.Office.Irm.OfcProtector.dll
另一种方式是采用加壳的方式在WordApplication外再套一层应用（文档编辑器），就类似与RMS所做的那样，当然，要保持与RMS相兼容。
2、 服务器端生成的可发行证书（IL）和最终用户协议（EUL）必须能够被客户端识别，该证书必须与客户端证书相匹配，并且被正常使用。
3、 Protector由C＋＋开发，必须能够调用MOSS中的SPSite、SPSWeb、SPSUser等应用开发类，目前是否有该类的头文件和类型库文件还是未知，所以在与现有MOSS兼容性方面也还存在风险。
目前的想法是最好可以从MOSS数据库中直接读取相关信息，但关于文档库用户的身份权限信息是否能够被轻易取到也还是未知数。
目前主要能想到的最大难点就是上述三点，随着研究的深入进行，解决问题的同时肯定还会碰到更多的问题，但是该方案应该是被认为目前唯一可行且一定可行的方案。