关于用户角色权限管理一点想法

[Title ] 关于用户角色权限管理一点想法
[Author] Pizer.Chen
[Email ] Iceant@21cn.com | iceant@vip.163.com
[Date ] 2002-11-3

----------------------------------------------------------------------------
我以前设计过一个权限系统的模型，但是我没有实现，
可以说出来，大家讨论一下。

我认为一个系统的权限部分应该由以下四个部分组成:

[*] Resource
[*] Privilege
[*] Role
[*] User

另外，一个系统中最少有这么几个角色:
[*] Creator，也可以称做 Programmer.
[*] Administrator, 超级用户
[*] General User

----------------------
权限各部分之间的关系:
----------------------
1. Resource 就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象.

2. Privilege 是 Resource Related 的权限。
什么意思？就是指，这个权限是绑定在特定的资源实例上的。
比如说部门新闻的发布权限，叫做"部门新闻发布权限".
这就表明，该 Privilege 是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。
我认为，Privilege 是由 Creator 在做开发时就确定的。

3. Role, 是角色，拥有一定数量的权限。

4. User, 与 Role 相关。在我设计的系统里，User是不能与 Privilege 直接相关的，
User 要拥有对某种资源的权限，必须通过Role去关联.

----------------------
系统大串联:(^_^)
----------------------
下面简单介绍一下，一个权限从开发到使用的过程.

1. Creator 创造 Privilege, Creator 在设计和实现系统时会划分，一个子系统或称为模块，
应该有哪些权限. 拿新闻这一块来说，可能应该有：
[*] 发布权限(publish)
[*] 修改权限(modify)
[*] 审核权限(review)
[*] 浏览权限(visit)
.......
这里完成的是 Privilege 与 Resource 的对象申明，并没有真正将 Privilege 与具体
Resource 实例联系在一起.

2. Administrator 指定 Privilege 与 Resource Instance 的关联.
在这一步，权限真正与资源实例联系到了一起, 产生了 Privilege Instance。
比如，Administrator 创建了一个叫做 "部门新闻" 的Resource Instance.
然后将发布权限与这个资源相关联，产生出 "部门新闻发布权限" 这个 Privilege Instance.

3. Administrator 创建一个角色，称做 "部门新闻发布者".

4. Administrator 将 "部门新闻发布权限" 赋予 "部门新闻发布者".

5. Administrator 从用户列表中选取一个或多个用户，
然后给这些用户赋予 "部门新闻发布者" 的角色

6. User 进到系统，在它的可访问资源列表上，会出现"部门新闻发布"的链接.

7. User 点击 "部门新闻发布"的链接, 根据 Creator 的实现，系统会检查
[1] 当前用户是否拥有发布权限
[2] 当前用户的发布权限是否与能操作正在访问的资源.

----------------------
结束语
----------------------
这是我一次在飞机场等飞机时突然设计出来的东西。因为没有具体实现，
而且也可能因为时间仓促，没有想得很透彻，希望写出来大家讨论一下。
具体实现上的技术问题，我也想过，我觉得应该已经想通，但是介于时间关系，
这里写不了啦，大家可以谈谈看法 .

你的方案应该行得通，但是我觉得可以再简化精练一点。
我的思路是这样。

用户角色权限，就设定用户user和角色role的对应关系，user还包括用户组group,　user和group的关系树形结构的关系。

所以，在系统权限这里，我们就可以围绕角色开始定义，抛开user或组的纠缠。如你所说resource 和function(Privilege)组合成一个角色。

提供一个强大的用户权限定制系统，就要在上面两个方面提供定制:
1.可以自行增加　删除　管理resource和function之间关系。
2.可以自行设定用户user和角色role的对应关系。

以你的部门新闻发布为例：
1.某一个新闻为resource . 发布权限(publish) 修改权限(modify)等为function(Privilege)，先设定好这两者关系，比如新闻+发布权限　作为一条记录存入数据库，ID就是roleID,这条记录其实就是一个角色。

2.设定user和roleID角色之间的关系，哪些user包含这个角色role。

通过上面两步设置，权限系统框架基本设定，一个用户登陆进来，可以按上面规则检查一下。

我这里与你的区别就是，权限部分应该由以下部分组成：

Role--|-Resource
|_Privilege
User

大家可以讨论一下。

上文权限系统应该为：


Role--|-Resource
      |_Privilege
User

banq你的意思是每个用户可以有多个角色，而我觉得每个用户就应该有一个角色，而角色可以有多种组合，这样合不合适？

我认为角色不易套角色，用户当然可以是多角色
我们每天不都在扮演不同的角色嘛

请教一下，你觉得怎么简化比较好?

我上面写了　实际将你4个元素简化成3个，角色不是独立的了。

我在上一个项目中曾经按照beng的提法做，发现和实际项目环境可能会有很大冲突。比如说，论坛权限--用户的需求是：按照不同部门来划分权限，技术部的论坛对于市场部来说是只读的。
后来采取的是一个折中的方案：其它模块按照角色设置权限，论坛模块则按照userId和departId(部门)来设置。
当然也可以想想办法把部门映射到角色上，但那样做的结果只会让原本简单的东西复杂化。
因此我觉得按照这个思想做出一个理想的模型很有好处，(至少可以归结一类问题的解决方案)，但在真正的项目中，还是要具体问题具体解决。模型不是万金油。

按照不同部门来划分权限，技术部的论坛对于市场部来说是只读的。

这就是我说的要产生资源+Privilege 的实例.

技术部论坛和市场部论坛都是论坛(Resource)的实例(Instance)
对于 Creator 来说，它们都有共同的Privilege set.
visit privilege, post privilege, reply privilege.....
所以，Creator 在开发时，就应该实现这些权限的控制.

对于管理员来说，他要做的就是
[1] 创建两个论坛实例:技术部论坛(TechForum)和市场部论坛(MarkForum).
[2] 创建角色: TechForumUser, BlockedTechForumUser 和 MarkForumUser
[3] 给角色分配权限:
TechForumUser[(visit,post,reply) on TechForum]
MarkForumUser[(visit,post,reply) on MarkForum]
[4] 将市场部的人都加入 MarkForumUser角色中
将技术部的人加入 TechForumUser + MarkForumUser 中
这样，市场部的人就不能访问 TechForum 上资源了

sorry,BlockedTechForumUser should be delete

ok,thanks.
确实可以这样实现。
实际应用环境中没有这么做，是因为对于系统管理员来讲需要将所有的技术部员工加入到一个角色中，觉得麻烦。而用departId来做权限验证就很方便了。

你说的没错，模型只是模型，不可能是万金油，
所以对不同的应用还是要做相应的修改。
你说的将整个部门一起加进去的问题，在现实确实不能一个个加。
应该做相应的改进，加入对整个部门操作的功能

欢迎讨论 ^_^ and 很高兴认识你

其实blues例子中，部门也是用户，是属于用户组的概念，部门和用户之间是树形支节点的关系。

部门也可以和角色确立对应关系，首先你建立这样的角色：对自己是创建者的资源(论坛)拥有一切权利，如果否，就只有读权限。

然后再将部门和这个角色对上号。

我觉得这样思路清晰。

如果user不与Privilege直接相关的是不是会有些问题？
例如一个amdinistrator地role有删除，修改，发布，浏览的权限，现在有一个用户需要具有发布赫浏览的权限，那么就需要重新建立一个role。这样的话，如果功能很多的话，那role地数量不可想象。
我觉得可以有 user,userGroup来规划用户，userGroup可以嵌套userGroup。user,userGroup与role建立关系，但是user,userGroup也可以单独分配Privilege。role存在地意义仅仅是Privilege的一个集合，方便分配合修改。

问得好，你说的增加用户组，我赞同!!!

Group 是 User 的集合.
Role 是 Privilege 的集合

从 OO 的角度来看，非常清楚。(I like it ^_^)

对于用户直接拥有权限，我还是不建议让用户直接与权限关联。

从实现的角度来看，权限的判断最后都是在检查当前用户是否拥有
需要的权限。也就是 [user,privilege] 这样的 pair 是否存在.
所以，给用户直接赋权是可以的。
但是我觉得这样使用，重用性不好，如果是通过 Role 来关联的话，
因为多了一层，所以灵活性更大，偶合性更小。出于这样的角度，我不建议那样用.