SharePoint中的权限体系

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 不支持定向继承。例如，对象只能从其父容器继承，而不能从某些其他对象或容器继承。

当网站继承角色定义时，这些角色是只读的，就像继承的网站中的只读权限一样。用户将获得导航到拥有独有角色定义的父网站的链接。所有新网站（包括拥 有独有权限的新网站）的默认设置都是从父网站继承角色定义。如果是独有权限，则角色定义可以还原为继承的角色定义，或编辑为本地角色定义。

根据下列禁止规则，网站中的角色定义继承对权限继承产生影响：

· 不能继承权限，除非它还继承角色定义。

· 不能创建独有角色定义，除非它还创建独有权限。

· 不能还原为继承的角色定义，除非它也还原网站中的所有独有权限。现有权限依赖角色定义。

· 不能还原为继承的权限，除非它也还原为继承的角色定义。网站的权限始终与网站的角色定义关联。