SharePoint 2010 中的用户访问控制（2）

xiaozhuaia

　　一、SharePoint Group, Permission Level, Permission
　　用户组、权限级别、权限
　　要说明这个SharePoint中最常用的用户访问控制手段，需要再加入一个概念：User（用户）。
　　需要说明的是，SharePoint 里面的所谓用户（User），其实是用户信息（User Profile）的副本。SharePoint 不是 IMS （Identity Management System），它只是从 IMS 里面复制一份用户信息过来，并且，它从来不对用户身份进行验证，因为验证用户身份是 IMS 的工作，不是SharePoint 的。SharePoint 只需要 IMS告诉它，现在登录的这个身份，是合法的还是不合法的就可以了。
　　这个IMS，可以是Windows Account，可以是Active Directory，可以是Form Based DB，可以是Federation，可以是任何 Claims Based Token Issuer；反正不可能是 SharePoint 自己。
　　这样，SharePoint 很清楚的划分出了自己的系统边界，防止了陷入IMS管理的泥潭，也给MS自家的Active Directory留了饭碗。这些用户信息副本存在一个UserProfile数据库中，大概是这个样子：

　　那为什么要有一个副本？因为每次要显示用户名、邮件地址都要去IMS找一圈的话，不仅影响性能而且有安全隐患。如你所见，这样就产生了一个新的问题：用户信息的同步。呵呵，以后再说这块儿吧。
　　（这也是为什么我觉得本来应该先整理关于用户身份验证的内容，再整理用户访问控制的原因。）
　　
　　这样，整个关系就变成了：

　　1、用户组包含用户；把用户组想象成文件夹，则用户就文件。
　　2、权限级别包含权限；把权限级别想象成文件夹，则权限就是文件。
　　3、用户、用户组可以和权限级别关联。
　　SharePoint 会查询出用户所具有的全部权限，然后决定给用户呈现何种信息。
　　
　　二、Permission（权限）
　　这是SharePoint 最细颗粒度的实际控制手段。系统内置，不可更改。
　　SharePoint 2010 内建33个权限，这些权限按照其控制的对象，分成3类。（说计算机是关于分类和分层的科学，一点儿都不假！）
　　分别是：Site Permissions、List Permissions、Personal Permissions。
　　33个权限之间，互有关联。比如，Manage Lists 权限就需要有 View Items, View Pages 等权限。从而织起了一张权限网。
　　具体的33个权限可以参考这里。
　　但是，你不能直接给用户或者用户组授予权限，而只能和权限级别关联。这样便于批量管理用户的权限，对于相同权限级别的用户，只需更改权限级别就可以将所有用户的权限修改好。当然，前提是你有一张清晰的权限和权限级别对应表。
　　
　　三、Permission Level（权限级别）
　　权限级别是可以自己定义的，将权限（Permission）打包的权限组，用户或者用户组只能和权限级别进行关联。
　　SharePoint 2010 默认提供了5个权限级别：Limited Access、Read、Contribute、Designe、Full Controll。
　　默认情况下，这5个就够用了。真正的问题在于，我们需要对不同的安全对象（Security Object）设置不同的权限级别，如果你的 SharePoint 应用有10几个网站、几十个列表，那么，设置、管理这些权限级别才是真正的挑战。
　　
　　四、权限矩阵
　　下面，我们应该开始做一件很难，但是，很有意义的事情。这件事情不需要编码，你无须打开VS，你甚至都不需要用电脑。但是如果你不做这件事就打开电脑、开始VS和编码，你以后可能就会没日没夜的加班。
　　再来看一眼这个图：

　　我们要把它，结合SharePoint 的Group、Permission Level、Permission，变成一个权限矩阵。这个矩阵如此重要，以至于我经常将它作为项目开始后的第三件事情来做。
　　这个矩阵需要一张或者几张A3的纸，每个Security Object一张。别拿A4的纸凑合，那肯定是画不下去的！
　　矩阵的左侧（行），写上按照权限级别分类的权限；矩阵顶部（列），写上用户的姓名；矩阵中间的单元格，用“√”标记用户与权限的关联关系。
　　就像这样（这只是一个示例）：

　　上面的示例中，可以看到，第一个和第三个用户（分别对应第三列和第五列），有相同的权限（都是2个“√”对应相同的权限）。那么，这就意味着你应该创建一个新的权限级别包含这2个权限，和一个新的用户组包含这2个用户，然后，关联它们。
　　
　　想做项目管理？很简单，画好上面这个矩阵，小心的保存起来并实时更新它。它就是你的“武器”，客户和团队将在这个矩阵面前被你从容的安排。
　　
　　五、权限继承
　　可是，事情还没有完。
　　从SharePoint 2010 的顶层网站到下面的子网站到下面的列表，权限是可以继承、也可以不继承的。
　　这样，我们需要再多考虑一件事情：到底继不继承？！
　　答案么，我认为还是应该在画出权限矩阵之后。顶层站点画一张，子站点画一张，对比看看。如果是一样的，就继承；否则，断开继承，给子站点单独设置。
　　
　　
　　六、Group（用户组）的可见范围
　　最后有个尾巴要说一下，就是在用户组设置里面的“谁能看到组的成员？（Who can view the membership of the group?”选项。
　　默认的选项是“仅组成员（Group Members）”，这本来没什么不好。但是，如果你要实现一个工作流，需要让申请人在提交前选择审批领导，而审批的领导又是在一个叫做“Manager”的单独的组里面的话，那么，还是选“每个人（Everyone）”吧，否则，申请人连领导都看不到了：）

　　
　　本篇结束。
　　“等等，你还没有说怎么操作，我没有看到系统截屏！”
　　呵呵，这个已经有人做了。就在我整理这篇随笔的时候，找到了这篇文章，里面已经写得相当全面了。