摘要：本文介绍如何实现 Microsoft SharePoint 产品和技术的代码访问安全策略，以及如何自定义 Microsoft Windows SharePoint Services 的默认安全设置。本文还回答了有关代码访问安全以及它在 Windows SharePoint Services 中的适用性的一些常见问题。（本文包含一些指向英文站点的链接。）

目录

简介
Windows SharePoint Services 中的默认安全权限
ASP.NET 与 SharePoint 安全策略
为虚拟服务器设置信任级别
常见问题
小结

Microsoft® ASP.NET v1.1 在安全方面的一项主要改进就是可以在部分受信任的环境中运行 Web 应用程序。有关详细信息，请参阅 What's New in the .NET Framework v1.1。这是在 ASP.NET v1.0 基础上的一项改进。在 ASP.NET v1.0 中，要求所有的 Web 应用程序必须是完全受信任的。由于 ASP.NET v1.1 启用了代码访问安全，因此，Windows SharePoint Services 就利用此功能使服务器管理员能够根据需要灵活地设置程序集的执行权限。

在 Windows SharePoint Services 平台上创建 Web 部件或自定义解决方案的开发人员，应该熟悉 Windows SharePoint Services 是如何实现自定义安全权限和策略文件的。Windows SharePoint Services 实现使开发人员可以为部分受信任的环境自定义应用程序。

Windows SharePoint Services 定义了两种默认安全权限，它们是 Microsoft.SharePoint.Security.dll 中 Microsoft.SharePoint.Security 命名空间的一部分，每种权限包括以下一种或多种属性：

SharePointPermission：控制对 Windows SharePoint Services 所使用的资源的访问权限。

WebPartPermission：控制对 Web 部件资源的访问权限

对于 ASP.NET 应用程序的预定义权限集，您可以指定一个与之对应的信任级别。默认情况下，ASP.NET 定义了以下信任级别：

• 完全
• 高
• 中
• 低
• 最低

除了“完全”信任级别以外，其他所有信任级别都仅向虚拟服务器实例的应用程序文件夹授予部分信任权限。有关 ASP.NET 信任级别的详细信息，请参阅 ASP.NET Code Access Security。

另外，Windows SharePoint Services 自己定义了两种信任级别：

• WSS_Minimal
• WSS_Medium

这两种信任级别为 Windows SharePoint Services 拓展了 ASP.NET 的“最低”和“中”信任级别。安全策略文件 wss_minimaltrust.config 和 wss_mediumtrust.config 中定义了这两种级别。默认情况下，Windows SharePoint Services 将这些文件存储到以下位置：

local_drive:\Program Files\Common Files\Microsoft Shared\web server extensions\60\config

默认情况下，当您使用 Windows SharePoint Services 扩展虚拟服务器时，Windows SharePoint Services 会将信任级别设置为 WSS_Minimal。这提供了一种安全信任级别，在这种级别中，程序集被授予执行代码所需的最小权限集。

下表列出了使用 Windows SharePoint Services 附带的自定义安全策略文件授予的一些特定权限。

注意：默认情况下，Windows SharePoint Services 不会授予 Microsoft SharePoint 对象模型的访问权限。要授予访问权限，必须通过某种方法提高相关联的信任级别。下一节将讨论有关方法。

通过 web.config 文件中 <trust> 标记的 level 属性值，可以确定虚拟服务器的信任级别。默认情况下，Windows SharePoint Services 将信任级别设置为 WSS_Minimal。在使用 Windows SharePoint Services 扩展的虚拟服务器的 web.config 文件中，可以找到以下 <trust>：

<trust level="WSS_Minimal" originUrl="" />

默认情况下，您可以使用上一节中列出的七种预定义信任级别中的任意一种。

注意：更改虚拟服务器的信任级别后，必须重设 Web 服务（可以使用 iisreset）。

在 web.config 文件中指定信任级别将产生以下结果：

• 在 web.config 文件中指定的信任级别将应用到指定的虚拟服务器所使用的所有程序集。
• 与指定的虚拟服务器相关联的所有 SharePoint 站点都采用相同的信任级别。

以下是有关代码访问安全以及 Windows SharePoint Services 的一系列问题。

部分信任对 Web 部件开发人员有什么意义？

如果将程序集安装到 BIN 目录中，则必须确保在不具有所需权限的情况下，您的代码可以进行错误处理。否则，未处理的安全异常可能会导致 Web 部件失败，并可能影响显示 Web 部件的页面的显示。

以下是安全异常的一个典型示例：

请求 
  Microsoft.SharePoint.Security.SharePointPermission, 
  Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, 
  PublicKeyToken=71e9bce111e9429c 类型的权限已失败

正如前面所提到的那样，对于应用程序的 BIN 目录中的程序集，WSS_Minimal 信任级别不会向其授予 SharePointPermission.ObjectModel 的访问权限。因此，如果代码试图使用 Microsoft SharePoint 对象模型，则公共语言运行库 (CLR) 将引发异常。

因为最小权限集提供的是执行代码所需的最小的一组权限，所以很可能出现其他的安全异常。

建议：尝试捕捉关键区域以处理那些没有所需权限来完成指定目标的情况。

如果我的程序集安装到 GAC 中怎么办？

默认情况下，安装在全局程序集缓存 (GAC) 中的程序集运行时具有“完全”信任级别。虽然可以将 Web 部件程序集安装在 GAC 中，但是为了实现更安全的部署，还是建议将它们安装在 BIN 目录中。

我怎样才能提高安装在 BIN 目录中的程序集的信任级别？

Windows SharePoint Services 可以使用 ASP.NET 和 CLR 提供的以下三种方法中的任意一种，来为安装在 BIN 目录中的程序集提供足够的权限。下表列出了每种方法的相关描述及要求。

我更改了 web.config 文件中的信任级别 - 现在我的整个站点都无法显示。我该怎么办？

如果在 web.config 文件中更改了信任级别，Windows SharePoint Services 可能无法按后续请求进行显示。以下是一个典型错误的示例：

程序集 <assemblyName> 安全权限授予集在 Appdomain 之间 
  不兼容。

要解决冲突的信任设置，可以使用 iisreset 来重设 Internet 信息服务 (IIS)。

注意：这是一个大家所熟悉的、与 ASP.NET 和 .NET Framework 体系结构有关的问题。

如何创建自定义策略文件？

要自定义一个内置策略文件，建议先制作一个副本，然后对此副本进行更改，以确保需要时还可以使用原始文件。

以下过程描述了如何向特定的程序集授予 Microsoft SharePoint 对象模型的访问权限。

要向程序集授予访问权限

1. 复制 wss_minimaltrust.config 文件。
2. 重命名 new_file_name.config 文件。
3. 使用文本编辑器（例如记事本）打开 new_file_name.config。
4. 在 <SecurityClasses> 元素中，添加 SharePointPermission 类的引用，如下所示：

   <SecurityClasses>
     <!-- 为了清楚起见，省略了其他安全类 -->
     <SecurityClass Name="SharePointPermission"
     Description="Microsoft.SharePoint.Security.SharePointPermission, 
     Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, 
     PublicKeyToken=71e9bce111e9429c" /> 
   </SecurityClasses>
   

5. 搜索 name 属性等于 ASP.Net 的 <PermissionSet> 标记。
6. 复制整个标记及其子标记，然后将副本粘贴到被复制内容紧邻的下方。
7. 将新 PermissionSet 元素的名称从 ASP.Net 改为 New_File_Name：

   示例（更改前）

   <PermissionSet class="NamedPermissionSet" version="1" Name="ASP.Net">
   <!-- <IPermission> 为了清楚起见，省略了节点 -->
     </PermissionSet>
   

   示例（更改后）

   <PermissionSet class="NamedPermissionSet" version="1" 
     Name="New_File_Name">
   <!-- <IPermission> 为了清楚起见，省略了节点 -->
     </PermissionSet>
   

8. 将以下 <IPermission> 节点添加到 name 属性等于 New_File_Name 的 <PermissionSet> 元素中：

   <IPermission class="SharePointPermission" 
                version="1" 
                ObjectModel="True" />
   

   这样，生成的自定义 <PermissionSet> 如下：

   <PermissionSet class="NamedPermissionSet" version="1" Name=" 
     New_File_Name">
     <IPermission class="AspNetHostingPermission" version="1" 
       Level="Minimal" /> 
     <IPermission class="SecurityPermission" version="1" Flags="Execution" 
       /> 
     <IPermission class="WebPartPermission" version="1" Connections="True" 
       /> 
     <IPermission class="SharePointPermission" version="1" 
       ObjectModel="True" /> 
   </PermissionSet>
   

9. 定义完自定义的元素后，必须创建一个代码组来指定 CLR 何时应用权限集。

   重要信息：默认情况下，AllCode 代码组是 ASP.NET 策略文件中的 FirstMatchCodeGroup。因此，在某个代码组符合首选代码组后，CLR 将停止为程序集指定权限。要应用自定义权限，必须将用于为程序集指定自定义权限的某个代码组声明为 AllCode 组中的首选代码组。这确保了 CLR 指定 MyCustomPermissions 权限集，并确保 CLR 停止指定权限，而不会继续进行直到默认的 $AppDirUrl$/* 代码组（此代码组用于根据程序集是否位于 BIN 目录中来指定权限）。

   在以下示例中，新代码组的成员身份条件基于严格命名的成员身份：

   <!-- 自定义组必须位于默认 ASP.NET 代码组之前 -->
   <CodeGroup class="UnionCodeGroup" 
              version="1" 
              PermissionSetName="MyCustomPermissions">
     <IMembershipCondition class="StrongNameMembershipCondition" 
                           version="1" 
                           PublicKeyBlob="... 参阅下列注释 ..." 
                           Name="MyAssemblyName" /> 
   </CodeGroup>
   

   注意：要检索程序集的公钥 blob，请使用 secutil.exe 工具，如下所示：

   secutil.exe -hex -s MyAssemblyName.dll
   

   有关 secutil.exe 的详细信息，请参阅 Secutil Tool。

10. 保存并关闭文件。现在可以使用策略文件了。
11. 打开使用 Windows SharePoint Services 扩展的虚拟服务器的 web.config 文件，然后将以下 <trustLevel> 标记添加到 SecurityPolicy 元素中：

      <trustLevel name="MyCustomTrustLevel" 
                  policyFile="new_file_name.config" /> 
    

    在 web.config 文件中，更改 <trust> 标记，使其引用新定义的信任级别。

    <trust level="MyCustomTrustLevel " originUrl="" />
    

12. 保存并关闭 web.config 文件。
13. 可以使用 iisreset 重设 IIS，将自定义策略应用到指定的虚拟服务器。

如果没有严格命名程序集怎么办？如何更改代码组？

您可以通过多种方法为代码组指定成员身份条件。可以使用 UrlMembershipCondition 来指定条件，如下所示：

<CodeGroup class="UnionCodeGroup" 
           version="1" 
           PermissionSetName="MyCustomPermissions">
  <IMembershipCondition class="UrlMembershipCondition" 
                        version="1" 
                        Url="$AppDirUrl$/bin/MyAssemblyName.dll" />
</CodeGroup>

我的程序集引用库程序集。当程序集安装在 GAC 中时，一切正常，但是一旦安装在 BIN 目录中时就出错。这是怎么回事？

如果您已向程序集授予了所需的权限，则程序集无法运行的原因可能与库程序集的构建方式有关。默认情况下，严格命名的程序集仅允许被授予完全信任权限的程序来调用。因此，CLR 将阻止部分受信任的程序集调用仅允许完全信任的程序才可以调用的程序集。

您可以选择以下几种可行的解决方案，其中有两种方案需要考虑安全问题：

1. 当编译程序集时，可以将 AllowPartiallyTrustedCallersAttribute 属性添加到指定的库程序集中。

   重要信息：您只能将该属性添加到源代码。如果使用的是第三方程序集，没有访问源代码的权限时，不能选择此方法。如果选择此方法，将允许部分受信任的程序执行库中的代码。这存在潜在的安全风险，因为它允许其他拥有部分信任权限的程序使用指定的库程序集。

2. 可以通过将程序集安装到 GAC 中来为其授予完全信任权限。

   重要信息：运行 Windows SharePoint Services 的服务器上的所有虚拟服务器和应用程序都可以使用安装在 GAC 中的程序集。这存在潜在的安全风险，因为它为大量程序集潜在地授予了比所需权限级别更高的权限。

3. 您可以按照上一节的描述，通过创建自定义策略文件向程序集授予完全信任权限。

   重要信息：建议选择此方法，因为使用它您可以明确地将所需的最小权限级别授予程序集，而不会扩大访问的范围，也不会将访问权限授予更多的程序。

我试图使用 Web 部件来访问 Web 服务。但每次都会出现如下所示的安全性异常：

请求 System.Net.WebPermission, System, 
  Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 
  类型的权限已失败。

默认情况下，BIN 目录中的程序集不具有所需的权限 System.Net.WebPermission 来访问 Web 服务。要授予此权限，需要将以下内容添加到相应策略文件的 IPermission 元素中：

<IPermission class="WebPermission" version="1">
  <ConnectAccess>
    <URI uri="...正则表达式形式的 URI..." />
  </ConnectAccess>
</IPermission>

我想通过 Web 部件访问 Web 服务。但每次都会出现如下所示的 InvalidOperationException：

由 XmlSerializer 引用的一个或多个程序集无法由部分
  受信任的代码调用。

当创建指向 Web 服务的引用时，Microsoft Visual Studio®.NET 会在程序集中创建并放置一个或多个对象，以存储传递给 Web 服务中方法的参数数据。当调用 Web 服务中的一个或多个方法时，会使用 XmlSerializer 类序列化这些对象。默认情况下，如果严格命名了程序集，并将其安装在 BIN 目录中，拥有部分信任权限的程序是无法访问该程序集中的对象的。当调用 Web 服务方法时，XmlSerializer 会检测到拥有部分信任权限的程序调用 callstack（即程序集），并且会阻止发生序列化，即使对象位于同一个程序集中。

您可以选择以下几种可行的解决方案，其中有两种方案需要考虑安全问题：

1. 可以将 AllowPartiallyTrustedCallersAttribute 属性添加到指定的库程序集中。

   重要信息：您只能将该属性添加到源代码。如果使用的是第三方程序集，没有访问源代码的权限时，不能选择此方法。如果选择此方法，将允许部分受信任的程序执行库中的代码。这存在潜在的安全风险，因为它允许其他拥有部分信任权限的程序使用指定的库程序集。

2. 可以通过将程序集安装到 GAC 中来为其授予完全信任权限。

   重要信息：运行 Windows SharePoint Services 的服务器上的所有虚拟服务器和应用程序都可以使用安装在 GAC 中的程序集。这存在潜在的安全风险，因为它为大量程序集潜在地授予了比所需权限级别更高的权限。

3. 您可以按照上一节的描述，通过创建自定义策略文件向程序集授予完全信任权限。

   重要信息：建议选择此方法，因为使用它您可以明确地将所需的最小权限级别授予程序集，而不会扩大访问的范围，也不会将访问权限授予更多的程序。

何处能了解到代码访问安全的详细信息？

有关代码访问安全的详细信息，请参阅以下内容：

• Introduction to Code Access Security
• AllowPartiallyTrustedCallersAttribute
• Security Optimizations
• Code Access Permissions

Windows SharePoint Services 使用自定义的 ASP.NET 策略并根据您的需要向程序集授予部分信任或完全信任权限。在使用 Windows SharePoint Services 创建自定义安全策略以确保运行自定义程序集的环境更加安全的过程中，开发人员和管理员可以使用现有的 ASP.NET 和代码访问安全知识。