深入理解程序集签名(强命名)

从开始做SharePoint开始到现在一直都是给程序强命名, 然后放到GAC修改web.config...也没有时间去深入的理解为什么要这样做, 前几天看到一本书中有讲到;

 

    签名(也称为强命名) 可以协助防止第三方的代码欺骗(假定SNK 文件是安全的). 当.NET Framework 装载程序集或将程序集安装在GAC时, .NET FrameWork 会校验该签名. 若不访问私钥, 恶意用户就无法修改签名代码,也就是无法对程序集重签名.

    签名可用于确定代码访问安全决策. 例如, 用企业的强命名密钥的代码可以与现在目录或数据库协同工作, 除非有执行代码的个人授权, 否则不溶于未签名的代码访问现有目录和数据库. 但是, 优于强命名不包含发布者的任何可靠信息, 因此信任内部密钥非常安全; 除非有一个安全的通道可用于获取公钥, 否则信任其他组织的密钥具有很大的风险.

    要注意非常重要的一点就是, 如果私钥泄露, 强命名就没有任何撤销机制. 如果企业的强命名密钥文件将用于建立信任, 就要确保不泄露该密钥文件, 可以将强命名的信任作用于特定的位置, 如特定的WSS v3场, 或者小到一个Intranet区. 如果泄露了强命名, 就必须重编译和复位信任度.

    如果将程序集部署到GAC, 就必须使用强命名.

 

    因此, 虽然并不是所有的场景都需要强命名程序集, 但强命名程序集方法的确是最佳的实践;

 

   如果签名了一个程序集, 并将它置入bin, 而不是GAC中, CAS就会阻止其他的程序集, 想Microsoft.SharePoint.dll就只有调用web部件程序集的部分可信任. 如果web部件准备好运行, 而CSA阻止WSS v3对它的调用, 这并不是一件好事, 所以, 在构建CAS的AssemblyInfo类中添加程序及指令, 以允许其他部分可信程序集条用该Web部件程序集.

 

  然后, WSS v3通过在web.config中为每个允许web部件运行的web应用程序布置一个SafeControl项, 来列出Web部件程序集. 该SafeControl需要一个完全合格的, 包含版本号的程序集名.

 

   使用GAC可以带来的优点:

 

   1. .NET Framework首先会搜索GAC, 所以程序集的加载速度要比在bin中快得多.

 

   2. 程序集都载入缓存.

 

   3. 由于GAC中所有的程序集都要签名, 部署程序集时(而不是使用程序集时)就可获得该程序集相关的技术细节, 因此使用程序集时所要做的工作就更少.

 

   但是GAC也面临许多挑战(特别是对开发而言):

 

   1. 调试非常麻烦, 可通过PDB添加到GAC MSIL目录来完成, 该目录包含相关的DLL, 目录地址为%systemroot%Assembly/GAC_MSIL.

 

   2. 自动将程序集考虑为完全信任级别. 如果程序集没有完全信任级别, 或者其目的只是为了测试, 就会带来一些问题.

 

   3. 运行的程序集可来自任何地方, 而不仅仅是已验证的WSS v3 web应用程序.

 

   4. 因为程序集已经存在于缓存中, 所以只升级程序集是不够的. 因此, 每次改变程序集时, 开发者必须清除缓存(或等待足够长的时间让缓存过期). 而部署到bin时, 就不用进行该操作;