一、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数据库中,大概是这个样子:

image

那为什么要有一个副本?因为每次要显示用户名、邮件地址都要去IMS找一圈的话,不仅影响性能而且有安全隐患。如你所见,这样就产生了一个新的问题:用户信息的同步。呵呵,以后再说这块儿吧。

(这也是为什么我觉得本来应该先整理关于用户身份验证的内容,再整理用户访问控制的原因。)

 

这样,整个关系就变成了:

image

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和编码,你以后可能就会没日没夜的加班。

再来看一眼这个图:

image

我们要把它,结合SharePoint 的Group、Permission Level、Permission,变成一个权限矩阵。这个矩阵如此重要,以至于我经常将它作为项目开始后的第三件事情来做。

这个矩阵需要一张或者几张A3的纸,每个Security Object一张。别拿A4的纸凑合,那肯定是画不下去的!

矩阵的左侧(行),写上按照权限级别分类的权限;矩阵顶部(列),写上用户的姓名;矩阵中间的单元格,用“√”标记用户与权限的关联关系。

就像这样(这只是一个示例):

image

上面的示例中,可以看到,第一个和第三个用户(分别对应第三列和第五列),有相同的权限(都是2个“√”对应相同的权限)。那么,这就意味着你应该创建一个新的权限级别包含这2个权限,和一个新的用户组包含这2个用户,然后,关联它们。

 

想做项目管理?很简单,画好上面这个矩阵,小心的保存起来并实时更新它。它就是你的“武器”,客户和团队将在这个矩阵面前被你从容的安排。

 

五、权限继承

可是,事情还没有完。

从SharePoint 2010 的顶层网站到下面的子网站到下面的列表,权限是可以继承、也可以不继承的。

这样,我们需要再多考虑一件事情:到底继不继承?!

答案么,我认为还是应该在画出权限矩阵之后。顶层站点画一张,子站点画一张,对比看看。如果是一样的,就继承;否则,断开继承,给子站点单独设置。

 

 

六、Group(用户组)的可见范围

最后有个尾巴要说一下,就是在用户组设置里面的“谁能看到组的成员?(Who can view the membership of the group?”选项。

默认的选项是“仅组成员(Group Members)”,这本来没什么不好。但是,如果你要实现一个工作流,需要让申请人在提交前选择审批领导,而审批的领导又是在一个叫做“Manager”的单独的组里面的话,那么,还是选“每个人(Everyone)”吧,否则,申请人连领导都看不到了:)

image

 

本篇结束。

“等等,你还没有说怎么操作,我没有看到系统截屏!”

呵呵,这个已经有人做了。就在我整理这篇随笔的时候,找到了这篇文章,里面已经写得相当全面了。

posted on 2011-06-30 11:22  JonyZhu  阅读(1511)  评论(0编辑  收藏  举报