1.MOSS中的權限結構

MOSS中的權限結構主要有三部分：網站權限，列表權限，個人權限。

網站權限由18種如下圖：

列表權限由12種，如下圖：

個人權限由三種，如下圖：

2.權限級別

上面提供的就是基本的權限，不同的權限組成MOSS中的權限級別。MOSS本身為我們提供了一些權限級別，我們也可以根據自己的需求來自定義。

我們在自定義自己的權限級別的時候可以參考Moss本身的，在他的基礎上進行修改，我們編輯現有的網站級別，里面提供了一個復制權限級別的功能，
我們可以復制一份在這個基礎進行修改來定義我們自己的權限級別。

3.下圖展示了MOSS權限，用戶和權限對象之間的關系：

4.使用SharePoint對象模型控制權限

主要使用下面幾個類：

SPUser，SPGroup，SPRoleDefinition，SPRoleAssignment。

SPRoleDefinition用于角色（即前面所說的“權限級別”）的定義

它的幾個重要的屬性有：

Name：角色名稱
Description：角色描述
BasePermissions：角色的權限（就是在這個地方指定詳細的權限）
另外，Type屬性是SPRoleType枚舉類型的，關于權限的枚舉是SPBasePermissions

SPRoleAssignment用于權限的分配，它比較簡單，只有三個public的屬性：

Member：把權限分配給誰
Parent：在什么東西上分配權限
RoleDefinitionBindings：分配什么權限

Member是SPPrincipal類型的是SPUser和SPGroup的父類
Parent：實現了ISecurityxxxx接口
RoleDefinitionBindings：可以理解為SPRoleDefinition的一個集合

在2007里面每一個能分配權限的東西（SPWeb、SPList、SPListItem等）都會有一個RoleAssignments屬性，它是一個SPRoleAssignmentCollection類型的屬性，
用于分配權限

此外，在SPWeb里還有RoleDefinitions屬性（只在SPWeb里有，也就是說角色只能定義在網站里）

舉例如下：

我們要給一個用戶（user）分配一個在列表（list）上的權限，權限使用了一個名叫“xxx”的角色

代碼如下：

SPRoleAssignment ra = new SPRoleAssignment(user);

SPRoleDefinition rd = web.RoleDefinitions["xxx"];

ra.RoldDefinitionBindings.Add(rd);

list.RoleAssignments.Add(ra);

又比如，修改一個用戶的權限：

SPRoleAssignment ra = list.RoleAssignments.GetAssignmentByPrincipal(user);

SPRoleDefinition rd = web.RoleDefinitions["xxx"];

ra.RoldDefinitionBindings.Add(rd);

ra.Update();但是，如果這個列表的權限之前是繼承自網站的，

那么上面的代碼并不會自動的修改這種繼承，反而會拋出異常

我們必須手工解除這種繼承關系：

list.BreakRoleInheritance(true);

參數中true的意思是把繼承下來的權限重新copy過來（如果你不改它的話，它和網站的權限還是一樣的），如果是false，則使用列表模版中定義的默認權限

如果要新建一個角色的話，直接new一個SPRoleDefinition，改改它的Name、Description、BasePermissions屬性，然后再加到web.RoleDefinitions里就可以了；
或者在new的時候可以選擇一個現有的角色copy過來，再改一改。這個代碼我就不寫了

此外，在權限方面還有一些其他的小改動：

在2003里，使用xxx.Permissions得到xxx（可以是SPWeb、SPList）的權限，但是在2007里Permissions屬性也被廢棄了

我們記得Permissions有一個非常有用的東西叫DoesUserHavePermissions來判斷當前用戶權限的，

在Permissions屬性被廢棄掉之后，這個方法移植到了SPWeb、SPList等類里

直接使用list.DoesUserHavePermissions就ok了

而且，現在這個方法不僅可以判斷當前用戶的權限，也可以判斷指定用戶的權限（通過SPUser）

另外，SPWeb、SPList及SPListItem也加入了CheckPermissions方法來判斷用戶權限，如果沒有則丟一個異常出來，這和以前的xxx.Permissions.Demand方法是一致的

5.角色定義，分配，繼承

角色由兩部分組成：角色定義和角色分配。

角色定義，或者說權限級別，是與角色關聯的權限列表。權限是 SharePoint 網站中唯一可控制的操作。例如，具有 Read 角色的用戶可以瀏覽網站中的頁面并查看列表中的項目。與 Windows SharePoint Services 2.0 中不同，在 Windows SharePoint Services 3.0 中，從不直接使用權限來管理用戶權限。所有用戶權限和組權限都通過角色來管理。角色定義是與特定對象綁定的權限集合。角色定義界定于網站范圍內（例如，Full Control、Read、Contribute、Design 或 Limited Access），并且在網站內的各個位置具有相同的意義，但其在同一個網站集內各網站之間的可能有所不同。角色定義也可以從父網站繼承，就像權限一樣。

角色分配是角色定義、用戶和組以及范圍之間的關系（例如，一個用戶可能是列表 1 上的讀者，而另一個用戶是列表 2 上的讀者）。通過角色分配表示的關系是使 Windows SharePoint Services 安全管理基于角色的關鍵。所有權限都通過角色來管理；您從不向用戶直接分配權限，而只分配定義完善、一致、含義豐富的權限集合（角色定義）。通過角色分配向角色定義中添加或從中移除用戶和組，以此來管理獨有權限。

網站管理員可以使用“管理角色”頁來自定義默認角色定義和創建其他自定義角色，其中，“管理角色”頁列出了網站中可用的角色定義。

角色定義繼承

Windows SharePoint Services 支持繼承角色定義，就像它支持繼承權限那樣，而取消角色定義繼承也要求取消權限繼承。

每個 SharePoint 對象都可以擁有自己的權限集，也可以從其父容器繼承權限。Windows SharePoint Services 不支持部分繼承，對象將繼承其父級的所有權限，并且也可以擁有一些自己的權限。權限可以是獨有的，也可以是繼承的。Windows SharePoint Services 不支持定向繼承。例如，對象只能從其父容器繼承，而不能從某些其他對象或容器繼承。

當網站繼承角色定義時，這些角色是只讀的，就像繼承的網站中的只讀權限一樣。用戶將獲得導航到擁有獨有角色定義的父網站的鏈接。所有新網站（包括擁有獨有權限的新網站）的默認設置都是從父網站繼承角色定義。如果是獨有權限，則角色定義可以還原為繼承的角色定義，或編輯為本地角色定義。

根據下列禁止規則，網站中的角色定義繼承對權限繼承產生影響：

· 不能繼承權限，除非它還繼承角色定義。

· 不能創建獨有角色定義，除非它還創建獨有權限。

· 不能還原為繼承的角色定義，除非它也還原網站中的所有獨有權限。現有權限依賴角色定義。

· 不能還原為繼承的權限，除非它也還原為繼承的角色定義。網站的權限始終與網站的角色定義關聯。

轉載于:https://www.cnblogs.com/greeny/archive/2010/09/03/1816945.html

總結

以上是生活随笔為你收集整理的SharePoint中的权限体系的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。