使用 SharePoint 进行安全性编程.docx
- 文档编号:10579218
- 上传时间:2023-02-21
- 格式:DOCX
- 页数:18
- 大小:74.15KB
使用 SharePoint 进行安全性编程.docx
《使用 SharePoint 进行安全性编程.docx》由会员分享,可在线阅读,更多相关《使用 SharePoint 进行安全性编程.docx(18页珍藏版)》请在冰豆网上搜索。
使用SharePoint进行安全性编程
OfficeSpace
使用SharePoint2007进行安全性编程
TedPattison
代码下载位置:
OfficeSpace2008_02.exe(209KB)
BrowsetheCodeOnline
目录
外部安全主体和SPUser对象
添加已通过身份验证的用户和外部用户
使用权限级别
WSS组
标识、提升和模拟
安全对象
结束语
您可能已经对使用Windows®和ASP.NET的安全性进行安全编程的基础有所了解,但您对WindowsSharePoint®Services3.0(WSS)增加的安全保护又了解多少呢?
在本期的OfficeSpace专栏中,我将重点介绍WSS引入的一些新的安全术语和概念,并为您展现一个使用WSS对象模型实现安全编程的新世界。
建议您下载本专栏附带的示例项目,并按照本专栏其他部分提供的代码执行操作。
该项目已配置为在构建过程完成之后运行一个批处理文件,该批处理文件会将所有的项目组件编译成一个WSS解决方案包,并在本地WSS服务器场中安装该包。
在建立项目并安装解决方案之后,您可以浏览任意网站集,并启用针对网站集的名为“SecurityDemo”的功能。
然后您就可以通过“网站操作”菜单导航到自定义应用程序页,这些页面通过一些代码演示了WSS安全编程技术。
外部安全主体和SPUser对象
大多数安全模型都是基于安全主体的。
每个安全主体均表示一个用户或一个组。
用户拥有帐户,并通过这些帐户进行身份验证。
身份验证完成后,每位用户将获得一个身份标识。
当用户使用Windows帐户进行身份验证时,您可以使用System.Security命名空间中的Microsoft®.NETFramework安全类来检索身份标识,该标识回指到特定的Windows帐户并允许您查看该用户的登录名:
复制代码
WindowsIdentityidentity=WindowsIdentity.GetCurrent();
stringWindowsLogin=identity.Name;
使用WindowsIdentity,您可以动态地创建一个WindowsPrincipal,该对象允许您通过测试查看当前用户是属于ActiveDirectory®组还是本地Windows组,如下所示:
复制代码
WindowsIdentityidentity=WindowsIdentity.GetCurrent();
WindowsPrincipalprincipal=newWindowsPrincipal(identity);
if(principal.IsInRole(@"LITWAREINC\AllFTE")){
//performoperationallowedforfulltimeemployees
}
ASP.NET同时支持Windows身份验证和基于表单的身份验证(FBA)。
ASP.NET中的User对象通过基于IPrincipal接口(而非WindowsPrincipal类)进行建模的方式摆脱了对Windows帐户的依赖性。
ASP.NET运行库根据当前用户是使用Windows帐户还是使用FBA帐户进行身份验证,来动态创建不同类型的IPrincipal对象:
复制代码
IPrincipalAspUser=HttpContext.Current.User;
stringAspUserName=AspUser.Identity.Name;
ASP.NET的User对象还提供了使用IsInRole方法检查用户是否属于特殊角色的方式。
对于Windows用户,IsInRole方法让您能够查看当前用户是否为ActiveDirectory组的成员。
如果您使用的是ASP.NET角色提供程序附带的FBA帐户,也可以使用IsInRole方法来检查是否已将FBA用户添加到特定的ASP.NET角色:
复制代码
IPrincipalAspUser=HttpContext.Current.User;
if(AspUser.IsInRole("SiteAdministrators"){
//performprivilegedoperation
}
身份验证操作会生成某种形式的回执,系统在运行时使用该回执来表示用户身份,以及对组或角色中的成员资格进行跟踪。
如果用户使用Windows帐户进行身份验证,则身份验证的回执为Windows安全令牌。
如果用户使用FBA帐户进行身份验证,则身份验证的回执为由ASP.NET运行库和特定身份验证提供程序创建的一个HTTPCookie。
了解WSS不支持用户身份验证这一点是十分重要的。
但WSS可以利用各种ASP.NET身份验证提供程序提供的底层身份验证组件。
WSS对于网站安全保护的价值在于它能够对授权和访问控制进行配置。
WSS能够在网站集范围内对外部安全主体(例如,Windows用户、FBA用户、Windows组和ASP.NET角色)进行跟踪。
借助WSS,您还可以配置分配给这些外部主体的权限,实际上是授予用户访问WSS安全对象(例如网站、列表、项和文档)的权限。
请注意,网站集在配置授权和访问控制时发挥了极其重要的作用。
在跟踪外部主体和配置权限时,WSS将每个网站集视为其彼此独立的孤岛。
WSS的高级设计有意将每个网站集隔离开来,以便一个网站集中的用户安全设置不会影响到其他网站集中的权限或访问控制策略。
WSS对象模型使用SPUser对象来表示外部安全主体。
您可以通过当前的SPWeb对象检索当前用户的SPUser对象:
复制代码
SPWebsite=SPContext.Current.Web;
SPUseruser=site.CurrentUser;
stringDisplayName=user.Name;
stringLogin=user.LoginName;
stringEMail=user.Email;
stringUserNotes=user.Notes;
SPUser对象公开了外部安全主体的各种属性,例如,登录名、显示名称和电子邮件地址。
将外部主体添加到网站时,通常可以从底层用户存储库(例如ActiveDirectory域)中检索到这些属性。
SPUser对象还提供了用于跟踪特定于WSS的元数据的属性,例如“注释”字段。
WSS将外部用户、组和角色的配置文件数据保留在隐藏列表(称为“用户信息列表”)中。
WSS每次提供新的网站集时,会在首要站点中自动创建“用户信息列表”作为隐藏列表。
然后,当首次为主体分配权限时,或主体首次通过安全检查访问安全对象时,WSS会为每个外部主体添加一个新的配置文件。
请注意,“用户信息列表”中存储的用户配置文件不能跨网站集进行扩展-用户更新一个网站集中的配置文件设置后,不会对其他网站集中该用户的配置文件设置造成更改。
另一个易混淆的地方就是SPUser对象通常并不总是代表实际用户。
SPUser对象也可以代表ActiveDirectory组和ASP.NET角色。
WSS不仅跟踪“用户信息列表”中每种外部主体的配置文件,而且还跟踪外部用户的配置文件数据。
SharePoint安全模型的许多编程方面的内容都是通过SPWeb对象在网站级别公开。
如果您要查看哪些用户是当前网站的成员,就会发现这一点。
一个SPWeb对象可公开三种不同的用户集合,如以下代码段所示:
复制代码
SPWebsite=SPContext.Current.Web;
SPUserCollectionc1=site.Users;
SPUserCollectionc2=site.AllUsers;
SPUserCollectionc3=site.SiteUsers;
Users集合是三个集合中包含成员最少的集合。
该集合包含了当前网站中所有已显式分配了权限的外部主体。
AllUsers集合包括Users集合中的所有成员,以及通过组或角色成员资格使用隐式权限访问过网站中的对象的外部用户。
例如,假定名为Brian的用户(登录名LITWAREINC\BrianC)从未被显式授予访问某个网站和查看特定列表的权限。
但他也许仍可以查看列表,因为他所属的ActiveDirectory组已被配置了列表查看权限。
当Brian首次访问网站或其中任一对象(比如,使用隐式权限查看一个列表)时,他会被添加为AllUsers集合的成员,但不会被添加为Users集合的成员。
SiteUsers集合是包含了当前网站集中每个AllUsers集合的成员的一个聚合。
该集合的成员包括所有已分配了对网站集中所有对象的访问权限的外部主体,以及所有已被授予使用隐式权限访问网站集中所有对象的权限的外部用户。
添加已通过身份验证的用户和外部用户
那么,如何为使用ActiveDirectory帐户通过身份验证的用户创建新的WSS用户配置文件?
如果您需要创建一个自定义用户界面组件,让标准用户或网站集所有者能够从ActiveDirectory域中选择用户或组,您确实应该了解一下PeoplePicker控件的用法(参见图1)。
这是WSS附带的一个便捷、可重用的控件类型。
您可以使用如下的控件标记将此控件添加到自定义应用程序页或User控件:
图1 PeoplePicker控件 (单击该图像获得较大视图)
复制代码
PeopleEditor ID="pickerPrincipal" AllowEmpty="false" ValidatorEnabled="true" MultiSelect="false" SelectionSet="User,SecGroup,DL" Width="280px" runat="server"/> 在此示例中,我对PeoplePicker控件进行了配置,为SelectSet属性分配了User、SecGroup和DL三个值。 通过配置这些SelectSet设置,该控件可以让用户根据ActiveDirectory选择和解析用户、组或通讯组列表。 您可以通过编程方式访问PeoplePicker控件属性,以便在用户使用该控件选择一个或多个安全主体后检索基本帐户的相关登录帐户名。 然后,您可以编写代码来实际将这些主体添加为网站成员并为其配置访问权限。 现在,我来介绍如何将外部用户或组添加为网站成员。 简单了解WSS对象模型之后,您可能会认为只需将外部安全主体直接添加到某个SPUser集合(例如SiteUsers)即可: 复制代码 SPWebsite=SPContext.Current.Web; site.SiteUsers.Add(@"LITWAREINC\BrianC", "brianc@", "BrianCox", "NotesaboutBrianCox"); site.SiteUsers.Add(@"LITWAREINC\AllFTE", "allFTE@", "AllFull-timeEmployees", "NotesaboutFTEDL"); 尽管这种方法确实能够在“用户信息列表”中为外部主体创建配置文件,但由于无法分配权限,因此对安全性几乎没有作用。 相比之下,添加新的外部安全主体的一个更好的方式是要对权限进行分配,以便用户有权访问当前网站。 但首先您需要学习如何创建和分配权限级别。 使用权限级别 权限级别是在网站范围内定义的权限命名集。 WSS内建了四个权限级别: Read(读取)、Contribute(参与讨论)、Design(设计)和FullAccess(完全访问)。 如果需要在级别设置上更为精细,可以使用WSS对象模型或通过网站集所有者能够访问的标准WSS管理页,创建属于自己的自定义权限级别。 权限级别有时称为角色,在WSS对象模型中通常使用SPRoleDefinition对象表示这些权限级别。 您可以使用SPRoleAssignment对象为外部用户或组分配权限级别。 例如,此处我将内置的Contribute权限级别分配给登录名为LITWAREINC\BrianC的Windows用户: 复制代码 SPWebsite=SPContext.Current.Web; SPRoleDefinitionrole=site.RoleDefinitions["Contribute"]; SPRoleAssignmentroleAssignment; roleAssignment=newSPRoleAssignment(@"LITWAREINC\BrianC", "brianc@", "BrianCox", "NotesaboutBrianCox"); roleAssignment.RoleDefinitionBindings.Add(role); site.RoleAssignments.Add(roleAssignment); 使用这种方法,您不必将用户添加到某一SPUser集合中,因为在网站内首次为外部用户或组分配权限时WSS已自动完成这一操作。 您刚才看到的代码会在“用户信息列表”中创建一个用户配置文件(如果原来不存在),并将该用户添加为当前网站的Users集合的成员。 WSS组 WSS安全模型不仅将外部安全主体表示为SPUser对象,而且还提供了WSS组,以方便网站集范围内的权限配置。 例如,您可以在网站集中为诸如SiteMembers(网站成员)、ContentManager(内容管理员)和SiteAdministrators(站点管理员)的特定用户角色设计一系列WSS组。 完成此项操作之后,您只需为WSS组分配权限级别即可配置网站的安全设置,而无需将权限级别直接分配给SPUser对象。 创建WSS组明显的好处是有助于消除添加或删除新的外部用户和组时重新配置权限的需要。 您只需创建网站时配置权限,即可做到一劳永逸。 之后,只需向WSS组中添加或从其中删除外部用户和组即可。 WSS组采用与ActiveDirectory组完全相同的设计原则,二者的主要区别在于WSS组仅在单个网站集范围内定义和存在。 WSS对象模型中将WSS组表示为SPGroup对象。 SPWeb对象公开两个SPGroup对象集合,分别为Groups和SiteGroups。 Groups集合包括当前网站中所有已直接分配权限的WSS组,而SiteGroups集合则是Groups集合的超集,其中包括所有在当前网站集内创建的WSS组。 如果您希望创建一个新的WSS组,您应该调用SiteGroups集合公开的Add方法,然后在目标网站内为新的WSS组分配一个或多个权限级别。 图2所示为新建一个名为SiteMembers的WSS组并在当前网站内为其分配内置Contribute权限级别的示例。 Figure 2 创建一个新的WSS组 复制代码 SPWebsite=SPContext.Current.Web; SPUsercurrentUser=site.CurrentUser; //createnewgroup site.SiteGroups.Add("SiteMembers",currentUser,currentUser, "SiteGroupcreatedat"+DateTime.Now.ToString()); //assignpermissionleveltonewgroup SPGroupNewGroup=site.SiteGroups["SiteMembers"]; SPRoleAssignmentroleAssignment=newSPRoleAssignment(NewGroup); SPRoleDefinitionpermLevel=site.RoleDefinitions["Contribute"]; roleAssignment.RoleDefinitionBindings.Add(permLevel); site.RoleAssignments.Add(roleAssignment); 新的WSS组创建完毕后,将外部用户和组添加为成员就变得轻而易举了。 由一个SPGroup对象提供一个AddUser方法,该方法接受一个SPUser对象,然后您就可以添加外部用户和组了: 复制代码 SPWebsite=SPContext.Current.Web; SPUsercurrentUser=site.CurrentUser; SPGroupgroup=site.SiteGroups["SiteMembers"]; SPUseruser1=site.SiteUsers[@"LITWAREINC\BrianC"]; SPUseruser2=site.SiteUsers[@"LITWAREINC\AllFTE"]; group.AddUser(user1); group.AddUser(user2); 标识、提升和模拟 WSSWeb应用程序的工作进程是通过IIS应用程序池进行控制的。 Web应用程序的工作进程标识可保证您对进程的关注,您可以通过SharePoint管理中心应用程序配置这些标识。 您应根据域帐户(例如LITWAREINC\SP_WorkerProcess)配置Web应用程序的工作进程标识,而不应根据本地帐户(例如NETWORKSERVICE)进行配置。 请注意,Web应用程序的工作进程标识必须是一个拥有特权的Windows帐户,该账户已配置了SQLServer权限,能够对一个或多个内容数据库进行读写操作。 运行SharePoint管理中心网站的Web应用程序的工作进程标识必须具有更多特权,因为它需要拥有对场的配置数据库进行读写操作的权限。 当Web部件或自定义应用程序页的代码响应用户请求开始执行时,该代码不会以托管Web应用程序的工作进程标识执行。 而是由WSS通过模拟将Windows安全上下文切换到其他Windows帐户。 实际上,如果您查看WSSWeb应用程序的web.config文件,会看到以下项: 复制代码 如果是为已使用Windows帐户进行身份验证的用户执行请求,则该请求会模拟当前用户的Windows标识。 但是,同样的方法并不适用于FBA用户,因为FBA身份验证不会创建Windows安全令牌,而且也没有Windows标识。 因此,使用FBA身份验证的用户的请求会模拟已经配置为匿名访问的Windows帐户的身份标识。 IIS中为此帐户默认分配的是IUSER_MACHINENAME帐户,但您可以(并且通常应该)重新配置此帐户以指向域帐户。 现在,让我们回过头来看一看更高级别的WSS安全编程。 WSS安全模型通常会强制要求开发人员对Windows标识和WSS用户标识加以区分。 但是在一个请求中,如果当前Windows标识和当前WSS用户标识都指向同一Windows登录名时,则上述情况可能不太明显。 而在使用FBA的情况下,事情就会变得更加复杂。 例如,WSS用户标识可能指向名为Andrew的FBA用户,而基本Windows标识则基于IUSER_MACHINENAME帐户。 当您的代码尝试访问WSS对象时,WSS会使用用户的WSS标识运行访问检查。 而当您的代码尝试访问WSS之外的外部对象(例如Windows操作系统维护的文件)时,操作系统会使用Windows标识(代码正以此标识执行)运行访问检查。 有时候要执行代码,您需要使用比当前用户权限更高的权限。 例如,我们可以假设这样一个情景: 在处理一个仅拥有只读权限的用户的请求时,您的代码必须向一个列表写入数据。 而默认情况下,您的代码要以与当前用户相同的权限来运行。 这时,您可以调用SPSecurity类的RunWithElevatedPrivileges方法,提升代码的安全上下文。 请注意,调用RunWithElevatedPrivileges将同时提升WSS用户标识和Windows标识。 现在想像这样一种情形: 用户通过登录名LITWAREINC\BrianC使用Windows帐户进行身份验证。 调用RunWithElevatedPrivileges会将WSS用户标识提升为SHAREPOINT\System帐户。 SHAREPOINT\System帐户内置于WSS运行库,在WSS授权模型中拥有完全的权限。 调用RunWithElevatedPrivileges还将切换执行代码的Windows标识,从而该代码以当前Web应用程序的工作进程标识运行: 复制代码 //BEFOREELEVATION //WSSUseridentity=LITWAREINC\BrianC //Windowsidentity=LITWAREINC\BrianC SPSecurity.RunWithElevatedPrivileges(delegate(){ //AFTERELEVATION //WSSUseridentity=SHAREPOINT\System //Windowsidentity=LITWAREINC\SP_WorkerProcess }); 在某些情景中,您可能会选择在尝试访问Windows文件系统或SQLServer数据库中的文件之前调用RunWithElevatedPrivileges方法,以便更改当前调用的Windows标识。 另请注意,如果您从Windows标识切换到进程标识(例如LITWAREINC\SP_WorkerProcess),则可以不必在ActiveDirectory环境下对委托进行配置。 当您的自定义Web部件能够使用Windows集成身份验证访问远程SQLServer数据库中的数据时,这项功能会非常有价值。 另外还会出现其他情景,您可能需要通过调用RunWithElevatedPrivileges方法将WSS用户标识提升为SHAREPOINT\System,以便您的代码能够执行在当前用户权限下不
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 使用 SharePoint 进行安全性编程 进行 安全性 编程
![提示](https://static.bdocx.com/images/bang_tan.gif)