MOSS身份安全的初步研究
MOSS身份安全的初步研究
MOSS是运行在IIS中的 ASP.NET应用程序，所以我们在学习、研究MOSS的安全机制时必需对IIS和ASP.NET的安全机制一并考虑。下图是一个MOSS安全机制的全貌。
一、IIS身份验证
处于最外围的是IIS的身份验证机制。Intranet中通常使用ACL身份验证或集成域身份验证。ACL是指Windows文件系统的访问控制列表，IIS通过客户端提供的用户名、密码与请求的文件ACL进行比较，可验证身份、权限；集成域身份验证的工作模式，委托域控制器进行身份验证，最广泛的身份验证方式。
二、ASP.NET身份安全
通过了外围IIS的身份验证，用户就可以请求到MOSS的页面了。MOSS页面代码如果要操作本地资源，那么ASP.NET需要决定按照什么样的身份来执行它。ASP.NET给开发人员提供了指定这个身份的可能——Web应用程序的配置文件中Indentity节点。下面列举了该节点三种可能的配置。
|
<identity impersonate="false" /> （或无该节点配制） |
使用运行Web应用程序的帐号身份来执行ASP.NET代码，默认情况下为本地“Network Service”帐号。 |
|
<identity impersonate="true" /> |
要求IIS传递客户端身份，并使用该身份来执行ASP.NET代码 |
|
<identity impersonate="true" username = “xxx” password = “xxx”/> |
使用username指定的帐号身份来执行ASP.NET代码 |
MOSS中一般使用表中的第二种配制，把客户端身份传递到web应用程序，以判断其访问MOSS内容的权限。
三、MOSS执行安全
部署在MOSS网站上的程序集的安全性受到两个方面的制约：一是程序集自身的受信级别，二是可调用程序集身份的受信级别。要提高程序集自身的受信级别，可以把程序集部署到GAC中，也在Web.config中把站点信任级别设为Full，如下所示：
<trust level=”Full” originUrl = “” />
实际上，这两种提升程序集权限的方法都有缺点，前者使程序集具有了本机的所有执行权限，后者使站点上所有程序集具有了Full权限。最安全的做法是编写一个策略文件，在策略文件中声明程序集有权限进行的操作。策略文件的写法，请看下面的示例，更详细的说明请查阅MOSS开发参考：
|
<configuration> <mscorlib> <security> <policy> <PolicyLevel version="1"> <SecurityClasses> <SecurityClass Name="UnionCodeGroup" Description="System.Security.Policy.UnionCodeGroup, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/> </SecurityClasses> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$AppDirUrl$/_app_bin/*" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="SPRestricted"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$AppDirUrl$/*" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust"> <IMembershipCondition class="UrlMembershipCondition" version="1" Url="$CodeGen$/*" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="Nothing"> <IMembershipCondition class="ZoneMembershipCondition" version="1" Zone="MyComputer" /> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Microsoft_Strong_Name" Description="This code group grants code signed with the Microsoft strong name full trust. "> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="002400000480000094000000060200000024000052534131000400000100010007D1FA57C4AED9F0A32E84AA0FAEFD0DE9E8FD6AEC8F87FB03766C834C99921EB23BE79AD9D5DCC1DD9AD236132102900B723CF980957FC4E177108FC607774F29E8320E92EA05ECE4E821C0A5EFE8F1645C4C0C93C1AB99285D622CAA652C1DFAD63D745D6F2DE5F17E5EAF0FC4963D261C8A12436518206DC093344D5AD293" /> </CodeGroup> <CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust" Name="Ecma_Strong_Name" Description="This code group grants code signed with the ECMA strong name full trust. "> <IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="00000000000000000400000000000000" /> </CodeGroup> </CodeGroup> </CodeGroup> </PolicyLevel> </policy> </security> </mscorlib> </configuration> |
程序集设用者的身份受其ACL的控制。我们可以通过修改程序集的ACL来控制Moss用户的调用行为。例如下面的操作，使所有用户都能执行QHH.Web.Dll程序集的代码并且可以访问位于该程序集上的资源（图片、JS角本等）。
四、MOSS内容访问安全
即使部署在MOSS上的程序集有了受信设置，也不能无限制的访问MOSS的内容。因为MOSS对其网站内容有更严格的访问控制。
假设，有一个只有网站管理员才可以修改的列表，一般用户只能查看该列表的内容。如果程序集中的代码对该列表进行了更新操作，就会导致一般用户收到“访问禁止”的错误信息。这时候必须通过SPSecurity.RunWithElevatePrivileges方法提升代码的权限。其用法如下
SPSecurity.RunWithElevatedPrivileges(delegate())
{
//需要提升权限的代码
}
另外，如果代码要操作网站的内容，必须创建新的SPSite和SPWeb对象。如下代码所示：
SPSecurity.RunWithElevatedPrivileges(delegate())
{
Using (SPSite site = new SPSite(SPContext.Current.Site.ID))
{
Using (SPWeb web = site.OpenWeb(SPContext.Current.Web.ID))
{
//此处操作网站内容
}
}
}
MOSS开发、应用中，经常会碰到有关身份安全的难题，如果能从本质上掌握它的工作原理，问题就可以迎刃而解了。
