MOSS/Sharepoint 用戶,權限,組,安全性 綜合OverView
您可能已經對使用 Windows® 和 ASP.NET 的安全性進行安全編程的基礎有所瞭解，但您對 Windows SharePoint® Services 3.0 (WSS) 增加的安全保護又瞭解多少呢？在本期的 Office Space 專欄中，我將重點介紹 WSS 引入的一些新的安全術語和概念，併爲您展現一個使用 WSS 對象模型實現安全編程的新世界。
建議您下載文章結尾附帶的示例項目，並按照本專欄其他部分提供的代碼執行操作。該項目已配置爲在構建過程完成之後運行一個批處理文件，該批處理文件會將所有的項目組件編譯成一個 WSS 解決方案包，並在本地 WSS 服務器場中安裝該包。在 建立項目並安裝解決方案之後，您可以瀏覽任意網站集，並啓用針對網站集的名爲“Security Demo”的功能。然後您就可以通過“網站操作”菜單導航到自定義應用程序頁，這些頁面通過一些代碼演示了 WSS 安全編程技術。
外部安全主體和 SPUser 對象
大多數安全模型都是基於安全主體的。每個安全主體均表示一個用戶或一個組。用戶擁有帳戶，並通過這些帳戶進行身份驗證。身份驗證完成後，每位用戶將獲得一個身份標識。當用戶使用 Windows 帳戶進行身份驗證時，您可以使用 System.Security 命名空間中的 Microsoft® .NET Framework 安全類來檢索身份標識，該標識回指到特定的 Windows 帳戶並允許您查看該用戶的登錄名：
複製代碼
WindowsIdentity identity = WindowsIdentity.GetCurrent();
string WindowsLogin = identity.Name;
使用 WindowsIdentity，您可以動態地創建一個 WindowsPrincipal，該對象允許您通過測試查看當前用戶是屬於 Active Directory® 組還是本地 Windows 組，如下所示：
複製代碼
WindowsIdentity identity = WindowsIdentity.GetCurrent();
WindowsPrincipal principal = new WindowsPrincipal(identity);
if( principal.IsInRole(@"LITWAREINC/AllFTE") ){
// perform operation allowed for fulltime employees
}
ASP.NET 同時支持 Windows 身份驗證和基於表單的身份驗證 (FBA)。ASP.NET 中的 User 對象通過基於 IPrincipal 接口（而非 WindowsPrincipal 類）進行建模的方式擺脫了對 Windows 帳戶的依賴性。ASP.NET 運行庫根據當前用戶是使用 Windows 帳戶還是使用 FBA 帳戶進行身份驗證，來動態創建不同類型的 IPrincipal 對象：
複製代碼
IPrincipal AspUser = HttpContext.Current.User;
string AspUserName = AspUser.Identity.Name;
ASP.NET 的 User 對象還提供了使用 IsInRole 方法檢查用戶是否屬於特殊角色的方式。對於 Windows 用戶，IsInRole 方法讓您能夠查看當前用戶是否爲 Active Directory 組的成員。如果您使用的是 ASP.NET 角色提供程序附帶的 FBA 帳戶，也可以使用 IsInRole 方法來檢查是否已將 FBA 用戶添加到特定的 ASP.NET 角色：
複製代碼
IPrincipal AspUser = HttpContext.Current.User;
if(AspUser.IsInRole("Site Administrators") {
// perform privileged operation
}
身份驗證操作會生成某種形式的回執，系統在運行時使用該回執來表示用戶身份，以及對組或角色中的成員資格進行跟蹤。如果用戶使用 Windows 帳戶進行身份驗證，則身份驗證的回執爲 Windows 安全令牌。如果用戶使用 FBA 帳戶進行身份驗證，則身份驗證的回執爲由 ASP.NET 運行庫和特定身份驗證提供程序創建的一個 HTTP Cookie。
瞭解 WSS 不支持用戶身份驗證這一點是十分重要的。但 WSS 可以利用各種 ASP.NET 身份驗證提供程序提供的底層身份驗證組件。WSS 對於網站安全保護的價值在於它能夠對授權和訪問控制進行配置。WSS 能夠在網站集範圍內對外部安全主體（例如，Windows 用戶、FBA 用戶、Windows 組和 ASP.NET 角色）進行跟蹤。藉助 WSS，您還可以配置分配給這些外部主體的權限，實際上是授予用戶訪問 WSS 安全對象（例如網站、列表、項和文檔）的權限。
請注意，網站集在配置授權和訪問控制時發揮了極其重要的作用。在跟蹤外部主體和配置權限時，WSS 將每個網站集視爲其彼此獨立的孤島。WSS 的高級設計有意將每個網站集隔離開來，以便一個網站集中的用戶安全設置不會影響到其他網站集中的權限或訪問控制策略。
1、SPUser
WSS 對象模型使用 SPUser 對象來表示外部安全主體。您可以通過當前的 SPWeb 對象檢索當前用戶的 SPUser 對象：
複製代碼
SPWeb site = SPContext.Current.Web;
SPUser user = site.CurrentUser;
string DisplayName = user.Name;
string Login = user.LoginName;
string EMail = user.Email;
string User Notes = user.Notes;
SPUser 對象公開了外部安全主體的各種屬性，例如，登錄名、顯示名稱和電子郵件地址。將外部主體添加到網站時，通常可以從底層用戶存儲庫（例如 Active Directory 域）中檢索到這些屬性。SPUser 對象還提供了用於跟蹤特定於 WSS 的元數據的屬性，例如“註釋”字段。
WSS 將外部用戶、組和角色的配置文件數據保留在隱藏列表（稱爲“用戶信息列表”）中。WSS 每次提供新的網站集時，會在首要站點中自動創建“用戶信息列表”作爲隱藏列表。然後，當首次爲主體分配權限時，或主體首次通過安全檢查訪問安全對象時，WSS 會爲每個外部主體添加一個新的配置文件。請注意，“用戶信息列表”中存儲的用戶配置文件不能跨網站集進行擴展 － 用戶更新一個網站集中的配置文件設置後，不會對其他網站集中該用戶的配置文件設置造成更改。
另一個易混淆的地方就是 SPUser 對象通常並不總是代表實際用戶。SPUser 對象也可以代表 Active Directory 組和 ASP.NET 角色。WSS 不僅跟蹤“用戶信息列表”中每種外部主體的配置文件，而且還跟蹤外部用戶的配置文件數據。
SharePoint 安全模型的許多編程方面的內容都是通過 SPWeb 對象在網站級別公開。如果您要查看哪些用戶是當前網站的成員，就會發現這一點。一個 SPWeb 對象可公開三種不同的用戶集合，如以下代碼段所示：
複製代碼
SPWeb site = SPContext.Current.Web;
SPUserCollection c1 = site.Users;
SPUserCollection c2 = site.AllUsers;
SPUserCollection c3 = site.SiteUsers;
Users 集合是三個集合中包含成員最少的集合。該集合包含了當前網站中所有已顯式分配了權限的外部主體。
AllUsers 集合包括 Users 集合中的所有成員，以及通過組或角色成員資格使用隱式權限訪問過網站中的對象的外部用戶。例如，假定名爲 Brian 的用戶（登錄名 LITWAREINC/BrianC）從未被顯式授予訪問某個網站和查看特定列表的權限。但他也許仍可以查看列表，因爲他所屬的 Active Directory 組已被配置了列表查看權限。當 Brian 首次訪問網站或其中任一對象（比如，使用隱式權限查看一個列表）時，他會被添加爲 AllUsers 集合的成員，但不會被添加爲 Users 集合的成員。
SiteUsers 集合是包含了當前網站集中每個 AllUsers 集合的成員的一個聚合。該集合的成員包括所有已分配了對網站集中所有對象的訪問權限的外部主體，以及所有已被授予使用隱式權限訪問網站集中所有對象的權限的外部用戶。
添加已通過身份驗證的用戶和外部用戶
那麼，如何爲使用 Active Directory 帳戶通過身份驗證的用戶創建新的 WSS 用戶配置文件？如果您需要創建一個自定義用戶界面組件，讓標準用戶或網站集所有者能夠從 Active Directory 域中選擇用戶或組，您確實應該瞭解一下 PeoplePicker 控件的用法（參見圖 1）。這是 WSS 附帶的一個便捷、可重用的控件類型。您可以使用如下的控件標記將此控件添加到自定義應用程序頁或 User 控件：
.gif)
圖 1 PeoplePicker 控件 (單擊該圖像獲得較大視圖)
複製代碼
<SharePoint:PeopleEditor
ID="pickerPrincipal"
AllowEmpty="false"
ValidatorEnabled="true"
MultiSelect="false"
SelectionSet="User, SecGroup, DL"
Width="280px"
runat="server" />
在此示例中，我對 PeoplePicker 控件進行了配置，爲 SelectSet 屬性分配了 User、SecGroup 和 DL 三個值。通過配置這些 SelectSet 設置，該控件可以讓用戶根據 Active Directory 選擇和解析用戶、組或通訊組列表。
您可以通過編程方式訪問 PeoplePicker 控件屬性，以便在用戶使用該控件選擇一個或多個安全主體後檢索基本帳戶的相關登錄帳戶名。然後，您可以編寫代碼來實際將這些主體添加爲網站成員併爲其配置訪問權限。
現在，我來介紹如何將外部用戶或組添加爲網站成員。簡單瞭解 WSS 對象模型之後，您可能會認爲只需將外部安全主體直接添加到某個 SPUser 集合（例如 SiteUsers）即可：
複製代碼
SPWeb site = SPContext.Current.Web;
site.SiteUsers.Add(@"LITWAREINC/BrianC",
"Brian Cox",
"Notes about Brian Cox");
site.SiteUsers.Add(@"LITWAREINC/AllFTE",
"All Full-time Employees",
"Notes about FTE DL");
儘管這種方法確實能夠在“用戶信息列表”中爲外部主體創建配置文件，但由於無法分配權限，因此對安全性幾乎沒有作用。相比之下，添加新的外部安全主體的一個更好的方式是要對權限進行分配，以便用戶有權訪問當前網站。但首先您需要學習如何創建和分配權限級別。
使用權限級別
權限級別是在網站範圍內定義的權限命名集。WSS 內建了四個權限級別：Read（讀取）、Contribute（參與討論）、Design（設計）和 Full Access（完全訪問）。如果需要在級別設置上更爲精細，可以使用 WSS 對象模型或通過網站集所有者能夠訪問的標準 WSS 管理頁，創建屬於自己的自定義權限級別。
權限級別有時稱爲角色，在 WSS 對象模型中通常使用 SPRoleDefinition 對象表示這些權限級別。您可以使用 SPRoleAssignment 對象爲外部用戶或組分配權限級別。例如，此處我將內置的 Contribute 權限級別分配給登錄名爲 LITWAREINC/BrianC 的 Windows 用戶：
複製代碼
SPWeb site = SPContext.Current.Web;
SPRoleDefinition role = site.RoleDefinitions["Contribute"];
SPRoleAssignment roleAssignment;
roleAssignment = new SPRoleAssignment(@"LITWAREINC/BrianC",
"Brian Cox",
"Notes about Brian Cox");
roleAssignment.RoleDefinitionBindings.Add(role);
site.RoleAssignments.Add(roleAssignment);
使用這種方法，您不必將用戶添加到某一 SPUser 集合中，因爲在網站內首次爲外部用戶或組分配權限時 WSS 已自動完成這一操作。您剛纔看到的代碼會在“用戶信息列表”中創建一個用戶配置文件（如果原來不存在），並將該用戶添加爲當前網站的 Users 集合的成員。
WSS 組
WSS 安全模型不僅將外部安全主體表示爲 SPUser 對象，而且還提供了 WSS 組，以方便網站集範圍內的權限配置。例如，您可以在網站集中爲諸如 Site Members（網站成員）、Content Manager（內容管理員）和 Site Administrators（站點管理員）的特定用戶角色設計一系列 WSS 組。完成此項操作之後，您只需爲 WSS 組分配權限級別即可配置網站的安全設置，而無需將權限級別直接分配給 SPUser 對象。
創建 WSS 組明顯的好處是有助於消除添加或刪除新的外部用戶和組時重新配置權限的需要。您只需創建網站時配置權限，即可做到一勞永逸。之後，只需向 WSS 組中添加或從其中刪除外部用戶和組即可。WSS 組採用與 Active Directory 組完全相同的設計原則，二者的主要區別在於 WSS 組僅在單個網站集範圍內定義和存在。
WSS 對象模型中將 WSS 組表示爲 SPGroup 對象。SPWeb 對象公開兩個 SPGroup 對象集合，分別爲 Groups 和 SiteGroups。Groups 集合包括當前網站中所有已直接分配權限的 WSS 組，而 SiteGroups 集合則是 Groups 集合的超集，其中包括所有在當前網站集內創建的 WSS 組。
如果您希望創建一個新的 WSS 組，您應該調用 SiteGroups 集合公開的 Add 方法，然後在目標網站內爲新的 WSS 組分配一個或多個權限級別。圖 2 所示爲新建一個名爲 Site Members 的 WSS 組並在當前網站內爲其分配內置 Contribute 權限級別的示例。
Figure 2 創建一個新的 WSS 組
複製代碼
SPWeb site = SPContext.Current.Web;
SPUser currentUser = site.CurrentUser;
// create new group
site.SiteGroups.Add("Site Members", currentUser, currentUser,
"Site Group created at " + DateTime.Now.ToString());
// assign permission level to new group
SPGroup NewGroup = site.SiteGroups["Site Members"];
SPRoleAssignment roleAssignment = new SPRoleAssignment(NewGroup);
SPRoleDefinition permLevel = site.RoleDefinitions["Contribute"];
roleAssignment.RoleDefinitionBindings.Add(permLevel);
site.RoleAssignments.Add(roleAssignment);
新的 WSS 組創建完畢後，將外部用戶和組添加爲成員就變得輕而易舉了。由一個 SPGroup 對象提供一個 AddUser 方法，該方法接受一個 SPUser 對象，然後您就可以添加外部用戶和組了：
複製代碼
SPWeb site = SPContext.Current.Web;
SPUser currentUser = site.CurrentUser;
SPGroup group = site.SiteGroups["Site Members"];
SPUser user1 = site.SiteUsers[@"LITWAREINC/BrianC"];
SPUser user2 = site.SiteUsers[@"LITWAREINC/AllFTE"];
group.AddUser(user1);
group.AddUser(user2);
標識、提升和模擬
WSS Web 應用程序的工作進程是通過 IIS 應用程序池進行控制的。Web 應用程序的工作進程標識可保證您對進程的關注，您可以通過 SharePoint 管理中心應用程序配置這些標識。您應根據域帳戶（例如 LITWAREINC/SP_WorkerProcess）配置 Web 應用程序的工作進程標識，而不應根據本地帳戶（例如 NETWORK SERVICE）進行配置。
請注意，Web 應用程序的工作進程標識必須是一個擁有特權的 Windows 帳戶，該賬戶已配置了 SQL Server 權限，能夠對一個或多個內容數據庫進行讀寫操作。運行 SharePoint 管理中心網站的 Web 應用程序的工作進程標識必須具有更多特權，因爲它需要擁有對場的配置數據庫進行讀寫操作的權限。
當 Web 部件或自定義應用程序頁的代碼響應用戶請求開始執行時，該代碼不會以託管 Web 應用程序的工作進程標識執行。而是由 WSS 通過模擬將 Windows 安全上下文切換到其他 Windows 帳戶。實際上，如果您查看 WSS Web 應用程序的 web.config 文件，會看到以下項：
複製代碼
<configuration>
<system.web>
<identity impersonate="true" />
</system.web>
</configuration>
如果是爲已使用 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 應用程序的工作進程標識運行：
複製代碼
// BEFORE ELEVATION
// WSS User identity = LITWAREINC/BrianC
// Windows identity = LITWAREINC/BrianC
SPSecurity.RunWithElevatedPrivileges(delegate() {
// AFTER ELEVATION
// WSS User identity = SHAREPOINT/System
// Windows identity = LITWAREINC/SP_WorkerProcess
});
在某些情景中，您可能會選擇在嘗試訪問 Windows 文件系統或 SQL Server 數據庫中的文件之前調用 RunWithElevatedPrivileges 方法，以便更改當前調用的 Windows 標識。另請注意，如果您從 Windows 標識切換到進程標識（例如 LITWAREINC/SP_WorkerProcess），則可以不必在 Active Directory 環境下對委託進行配置。當您的自定義 Web 部件能夠使用 Windows 集成身份驗證訪問遠程 SQL Server 數據庫中的數據時，這項功能會非常有價值。
另外還會出現其他情景，您可能需要通過調用 RunWithElevatedPrivileges 方法將 WSS 用戶標識提升爲 SHAREPOINT/System，以便您的代碼能夠執行在當前用戶權限下不允許的操作。一旦代碼能夠以 SHAREPOINT/System 身份運行，您就可以在 WSS 授權子系統中幾乎隨心所欲地執行任意操作。
調用 RunWithElevatedPrivileges 提升爲 SHAREPOINT/System 帳戶也有其相對棘手的一方面。例如，設想您調用 RunWithElevatedPrivileges，然後嘗試通過 SPContext.Current 屬性訪問當前網站集或網站中的對象。您也許想不到代碼會出錯，但事實可能出乎您的意料：
複製代碼
SPSecurity.RunWithElevatedPrivileges(delegate() {
SPSite siteCollection = SPContext.Current.Site;
// next line fails if current user is Contributor
string siteCollectionOwner = siteCollection.Owner;
});
爲什麼將 WSS 用戶標識提升爲 SHAREPOINT/System 之後本示例代碼會執行失敗？這與 SPSite 對象的創建時間有關。SPSite 對象及其子對象 SPWeb 的權限實際上並不依賴於當前 WSS 用戶標識。而是依賴於創建 SPSite 對象時的 WSS 用戶標識。在這裏，由於可通過 SPContext.Current 進行訪問的 SPSite 對象是在之前的請求中創建的，在該對象創建時，您的代碼還無法切換其 WSS 用戶標識。
因此，您需要使用一點技巧，在調用 RunWithElevatedPrivileges 並將 WSS 用戶標識提升爲 SHAREPOINT/System 之後，創建一個新的 SPSite 對象：
複製代碼
SPSecurity.RunWithElevatedPrivileges(delegate() {
using (SPSite elevatedSiteCollection = new SPSite(this.Site.ID)) {
using (SPWeb elevatedSite =
elevatedSiteCollection.OpenWeb(this.Web.ID)) {
// access elevatedSiteCollection and
//elevatedSite as SHAREPOINT/System
}
}
});
這樣就可以打開網站集及其中的網站，以便您的代碼能以 SHAREPOINT/System 身份訪問對象。
您可能還發現有必要模擬特定的 WSS 用戶標識。這種方式在爲事件處理程序或自定義工作流模板編寫代碼時（這種情況下代碼默認以 SHAREPOINT/System 身份運行）非常常見。例如，您可能希望在創建新對象之前模擬特定 WSS 用戶標識，以便 WSS 用戶能被識別爲新對象的所有者。
爲了模擬 WSS 用戶標識，您必須先創建一個 SPUserToken 對象。您可以使用 SPUser 對象的 UserToken 屬性實現這一操作。創建好 SPUserToken 對象之後，您就可以使用該對象利用 SPSite 類構造函數的重載版本來創建新的 SPSite 對象。此方法如圖 3 所示。
Figure 3 模擬 WSS 用戶標識
複製代碼
SPWeb siteCollection = SPContext.Current.Site;
SPWeb site = SPContext.Current.Web;
// get SPUser object and acquire token
SPUser targetUser = site.SiteUsers[@"LITWAREINC/BrianC"];
SPUserToken token = targetUser.UserToken;
// create new SPSite and SPWeb object to impersonate user
using (SPSite impersonatedSiteCollection =
new SPSite(siteCollection.ID, token)) {
using (SPWeb impersonatedSite =
impersonatedSiteCollection.OpenWeb(site.ID)) {
// WSS identity switched to impersonate BrianC
// Windows identity does not change
}
}
關於使用 WSS 用戶模擬，我需要指出幾點重要的注意事項。首先，模擬 WSS 用戶與調用 RunWithElevatedPrivileges 不同，因爲前者不會更改當前 Windows 標識。例如，如果在模擬 WSS 用戶之前一個請求以 LITWAREINC/SP_WorkerProcess 的 Windows 標識身份運行，則代碼將以同一 Windows 標識身份繼續運行。WSS 用戶模擬不會將當前 Windows 標識更改爲被模擬用戶的標識。
同樣需要注意的是，代碼要模擬另一個用戶，必須在特權狀態下運行。但在事件處理程序或自定義工作流模板中無需擔心這一問題，因爲在這類情況下代碼默認以 SHAREPOINT/System 身份運行。但是，Web 部件或自定義應用程序頁中的代碼在其有能力模擬其他 WSS 用戶標識之前可能需要調用 RunWithElevatedPrivileges。
安全對象
配置 WSS 安全性的真正優勢在於安全對象（例如網站、列表和列表項）提供的靈活性。每個安全對象都可以包含一個“訪問控制列表”(ACL)，這是一個二進制數據結構，WSS 在運行時會使用它來確定安全主體是否已被授予了訪問權限。默認情況下，首要網站是唯一擁有 ACL 的安全對象。子對象（例如列表、列表項和子網站）都繼承其父對象的 ACL，除非它們拒絕繼承並提供一個自己擁有的唯一 ACL。
WSS 對象模型中包含名爲 ISecurableObject 的接口，用於在 WSS 網站集中建立安全對象模型（參見圖 4）。ISecurableObject 接口是通過 SPWeb 對象、SPList 對象和 SPItem 對象實現的，它爲在運行時執行訪問檢查以及配置權限提供了基礎。
.gif)
圖 4 ISecurableObject 接口 (單擊該圖像獲得較大視圖)
當您着手在網站集中配置權限時，理解到所有網站、列表和列表項一起組成了安全對象的單一層次結構這一點是十分重要的。默認情況下，只有首要網站包含一個唯一的 ACL，並對權限級別的分配進行了定義，規定用戶需要獲得哪種權限才能訪問對象。所有子對象的權限都繼承自首要網站。但是，您可以爲安全對象提供一套屬於它自己的唯一權限級別分配，從而更加精細地配置訪問控制。例如，使用圖 5 所示的代碼，您可以創建一個新文檔庫，並使用一組唯一的權限對其進行配置。
Figure 5 配置一組唯一的權限
複製代碼
SPWeb site = SPContext.Current.Web;
Guid listID = site.Lists.Add("Proposals",
"Library desc",
SPListTemplateType.DocumentLibrary);
SPDocumentLibrary doclib = (SPDocumentLibrary)site.Lists[ListID];
doclib.OnQuickLaunch = true;
doclib.BreakRoleInheritance(false);
SPUser AllFteGroup = Web.SiteUsers[@"LITWAREINC/AllFTE"];
SPRoleAssignment assignAllFteGroup = new SPRoleAssignment(AllFteGroup);
SPRoleDefinition roleDesign = this.Web.RoleDefinitions["Read"];
assignAllFteGroup.RoleDefinitionBindings.Add(roleDesign);
doclib.RoleAssignments.Add(assignAllFteGroup);
doclib.Update();
此示例代碼通過調用 BreakRoleInheritance 取消了默認的對父對象的權限繼承關係。如果您調用 BreakRoleInheritance 並傳送一個 true 的參數值，安全對象最初會被配置一個與父對象 ACL 相同的副本 ACL。如果調用 BreakRoleInheritance 並傳送一個 false 的參數值，則安全對象最初會被配置一個空的 ACL。也就是說，此文檔庫對於既不是所有者也不是網站管理員的用戶不提供訪問權限。
Windows SharePoint Services 3.0 新增了一項很受歡迎的安全增強功能，讓您可以將權限的配置具體到項目級別或文檔級別。您可以通過 WSS 對象模型實現這一點，因爲 SPListItem 對象也實現了 ISecurableObject 接口。
圖 6 中的代碼在文檔庫中創建了一個新文檔，然後使用了一組與其父文檔庫不同的唯一權限進行配置。請注意，這段代碼使用了名爲 WriteDocument 的工具方法，可接受 SPDocumentLibrary 引用和文件名。該方法的實現使用 Office Open XML 文件格式創建 Word 文檔，然後將其寫回到文檔庫。WriteDocument 方法返回一個 SPFile 引用，該引用隨後可用於訪問與文檔相關的 SPListItem，這樣您就可以取消繼承關係並分配一組唯一的權限。
Figure 6 設置與其父對象不同的權限
複製代碼
SPWeb site = SPContext.Current.Web;
Guid listID = site.Lists.Add("Proposals",
"Library desc",
SPListTemplateType.DocumentLibrary);
SPDocumentLibrary doclib = (SPDocumentLibrary)Web.Lists[ListID];
doclib.OnQuickLaunch = true;
doclib.Update();
SPFile doc1 = WriteDocument(doclib, "Adventure Works Merger.docx");
doc1.Item.BreakRoleInheritance(false);
SPGroup group = Web.Groups["Litware Contact Managers"];
SPRoleAssignment assignContribute = new SPRoleAssignment(group);
SPRoleDefinition roleContibute = this.Web.RoleDefinitions["Contribute"];
assignContribute.RoleDefinitionBindings.Add(roleContibute);
doc1.Item.RoleAssignments.Add(assignContribute);
doc1.Item.Update();
結束語
我知道今天的討論稍微有些倉促，只是讓您對 WSS 的安全模型有一個大致的瞭解。我主要向您介紹了 WSS 如何使用“用戶信息列表”中的配置文件在網站集這一層上對外部安全主體進行跟蹤，以及 WSS 如何使用 SPUser 對象在 WSS 對象模型中表示這些外部安全主體。此外我還演示了 WSS 如何支持 WSS 組，並介紹了一些用於提升特權和模擬 WSS 用戶的編程技巧。在開發用於實際工作的應用程序時，這些技巧能夠爲您提供所需的靈活性和強大功能。
儘管 WSS 需要依靠基礎組件系統來執行身份驗證，但它確實能夠在授權和訪問控制方面發揮應有的作用。WSS 授權模型很大程度上基於一種被稱爲權限級別或角色的權限命名集。權限級別可以被分配給 SPUser 對象，但在實際應用中您通常應該選擇將權限級別分配給 WSS 組。