通常所说的权限实际是由两个部分组成:Resource(资源) + Access(操作方式).比如说创建目录,
删除目录,查看目录,这里的目录就是系统中的资源,是需要受保护的,而创建,删除和查看这些属于操作方
式.
权限系统中的权限可以分为粗粒度和细粒度两种,粗细粒度的区分的依据是资源.如果权限控制需
要针对资源的具体实例,那么这个权限就是细粒度的,否则就是粗粒度的.比如这里的查看目录权限就是一
个粗粒度的权限,而查看某个具体目录的权限即属于细粒度的权限.
细粒度的权限往往是和用户逻辑相关的,所以这不应该把它当作权限系统的一部分,而应当作用户
逻辑的一部分来处理.这样权限系统的设计易于理解,也便于实现.
Resource和Access的管理可以由两种方式来处理,一种是已经由系统预先定义好的,一种是有可以
有用户自己添加和组合,
后一种处理方式比较麻烦(无论对于用户和程序员来说),适合与应用比较复杂的场合.对于我们的
系统可以考虑预定义的方式
比如可以设置一个Permisson表,权限可以有:添加Category,添加Item,添加用户等等.
下面是Rescouce和Access组合的一个例子:
粗粒度:
Category Add
Edit
Delete
view
Item Add
Edit
Delete
view
User Add
Edit
Delete
view
细粒度:
张三的ategroy Add
Edit
Delete.
view
2.Role
权限的载体和分配单位,也是权限的集合.通常系统中权限都分配给Role.再把Role分配个User.这
由Role来作为User和权限的纽带.这样做是因为用户和角色之间的关系是容易变化的,而系统中一个角色的
权限通常是稳定不变的. Role对系统的贡献实质上就是提供了一个比较粗颗粒的分配单位
角色直接进行可以继承,孩子拥有父亲所有的权限.
如果系统中有User Group,有时也会把Role分配给User Group或者直接把权限分配给User Group,
此时Role也不是必需的.当用户加入到这个Group的时候,也就拥有了这个Group的权限.
3.User Group
通常定义成User的集合.我觉得权限系统引进User Group基于两种需求:
A. 需要以组的形式对某些具体的资源进行细粒度的权限控制(比如我创建的记录可以给同组的人
看和编辑)
Group中的User具有的角色和权限可以不一样.他们被分到一个组中的原因只是因为某些具体的资源.在这
个Group中,具有相同角色的User对于这个Group拥有的具体资源具有一样的访问能力.
在这里,User Group也不是必需的,比如可以通过增加细粒度的权限和角色来实现.例如:管理员为
我的这个记录增加读写权限,添加相应的角色,分配给不同的用户,那么他们也就拥有了对于这个记录不同
的权限.我每添加一条记录,就要做上述的操作,这样是不是很麻烦?
如果用User Group的话,那么管理员可以创建一个分组,把我和其他的用户分到一个组.具有记录
访问权限的用户想要访问我的记录只需要判断是否和我同组就可以了.但是由于User 和 User Group是多
对多的关系,那么这样的判断逻辑就会有一个问题:就拿我们要做的系统来说:
SystemAdmin 创建六个CP(Content Provider): A,B,C,D,E,F
创建3个地域(这里可以看作是Group): 北京,天津,上海
分配:
A,B==>北京
A,C,D==>天津
E,F==>上海
A,B具有相同的权限(都是CP),A可以管理北京和天津的内容.这没有问题,问题是如何判断B不可以
管理天津的内容呢?当B要访问天津的信息,如果仅仅判断B是否和A同组,那么这里的逻辑就会允许B也能够
访问天津的信息.要避免这种情况,我想为这些具体资源除了创建者的信息外,还需要记录这些具体资源所
属的组(比如用一张Category-Group表来记录),这和创建者所属的组的有关系.
比如A在创建信息的时候,他就可以选择发布到北京或者天津去.而C要创建信息,只能发布到天津
去.也就是这个记录所从属的组是天津.这样的话,那么当要决定B是否能访问天津的信息时,判断是否在这
个具体资源所在的组里就可以了.具体的判断如下
B是CP吗?
是-->B和要访问的信息是同组吗?
是-->允许访问
否-->拒绝
否-->拒绝
引入User Group的另外一个例子:
假设有几个用户具有不同的权限,职位也不一样,但是有一天需要他们共同合作一个项目,那么可
以为这些用户新建立一个用户组,并把该项目分配到这个用户组就可以了.在这个需求中,用户的权限没有
变化,部门也没有变化,所变化的是这些用户拥有了对于这个具体项目的控制权.管理员所做的只是把这些
用户放入一个组.一旦项目完成删除这个用户组就可以了.
有了组的概念后系统可以做的更加灵活,但是也会相对复杂.
B. 需要对User进行资源权限意义上的分组
从这个角度上进行的分组,通常一个分组中的User所具有的权限是一样的,比如有超级管理员组,
模块管理员组,用户组之类.
在引入这种类型的组的时候,Role不再分配给用户,而直接分配用给User Group.有的系统实现甚
至取消了Role,直接把权限分给User Group,把它作为了权限的载体.另外组可以继承组,组的孩子拥有父亲
的Role和权限.当把用户加入到User Group,那么这个用户也就拥有了这个Group的Role和权限.此时,User
Group和Role 其实所起的作用有些重叠,或者从另外一个意义讲,User Group就是换了名字的Role而已.
有些系统的使用更为复杂,Role 和 group同时存在,Role既可以给User,也可以给User Group,一
个Group中的用户所扮演的Role也不一样,用户可以和具体的资源进行权限联系,也可以由Group来进行联系
,这种系统的灵活性很高,但是对于管理员的要求也同样很高.
User Group的概念我觉得比较灵活,实际应用中如何使用还是得取决于系统的需求.
另外要注意权限的叠加问题.比如给某个用户分配了一个粗粒度的权限(比如Category Add),那么此时用
户就拥有在任何地方添加Categoy的权限.但是随后又把他加入到了一个组,这个组是和具体的资源联系的,
那么这个时候这个用户实际上权限受到了限制,他只能够在这个组所联系的资源中添加Caetgory.