WEB应用权限模块设计思想及方法

 

 

我也请教一个关于权限设计方面的问题

作者：ninsky 发表时间：2003年10月21日 22:31 回复

原贴网址： http://www.jdon.com/jivejdon/thread/10122.html

 

首先表示一下奇怪：我以前在这注册的号是不是给删除了，虽然我确实很久没在这发言了！

我现在在做一个系统，一个类似信息发布的东东，本来也无所谓，可没想到用户提出了许多BT的要求，尤其是权限方面，本来照我的常规思维，这种东东一般也就是划分几个角色，划分几个信息的发布模块等等也就行了，甚至公司都有现成的东西直接用。
可没想到客户的要求比较刁钻。我先说说系统的大概模样。
信息发布吗，首先当然要划分信息的类别和层次，而这层次是不定的，可能是两三层，也可能是十层、八层（没这么变态吧^_^），其实就类似与windows的资源管理器的样式，目录里面含着文件，而文件又有可能和目录平级的说，这是显示方面大概要显示的东东。现在说说他们在权限控制方面的要求，某个用户登录系统之后，这些目录文件（使用的是资源管理器类似的样式，左边一颗树，右边基本信息列表）将需要根据用户权限的不同而不同（有的目录文件显示，有的不显示的说），当然对于不同的记录用户也需要有不同的增删改权限，列表虽然都能看见，不过有的记录他可以修改却不可以删除，有的却连修改都不许了，当然还有其他的一下操作方式的控制。更为变态的是，要求点击某条记录（或目录、或文件）时弹出的信息查看页面对于不同权限的用户也需不同，即某些字段可以显示，某些字段不能显示（my god，还是把我回收了得了），这就要求在后台的管理方面有着灵活的操作，当然用户也要求了，本着易用性的原则，管理员可以适当选择是对一条条记录赋权还是对一批记录赋权。

说了这么多，不知道各位能否看明白？

我开始的想法是定义组，将某些权限相同的用户赋为一组，然后对记录赋权时根据组进行选择而不用对每个人进行选择，这样就不需对个人进行操作（即使一个人也给他搞个组），这样对组配置改组可以对记录有那些权限，可以显示记录的那些字段，然后针对记录选择组（一个用户可能属于多个组，如有重复，则以用户能获得的最大权限为主）。
不过后来一想，加入某些记录只是针对个人的，如果也这么做的话，会死人的啊，组的数量就太多了。

不过用户的这些要求说到底其实也挺合理，不过实现起来也确实挺头疼，反正我头疼了一个下午了，几张目录文件的表画好后，后台权限方面我死活下不了手了：（
我也希望能够趁这个系统的机会把这个权限管理好好核计核计，反正尽量希望能在设计阶段就考虑完善，最好能将权限这块尽量独立出来，将来在其他系统中可以比较方便地移至（估计也没那个信息系统有这么繁琐的要求了，本来不大的玩意，愣是让他们搞大发了）

但本人在设计方面是个新手，所以感觉难度实在挺大，还是先听听各位在座的高论先，请指教一下该如何下手，信息表与权限表该如何关联，如果有谁做过这方面的东东的话，那就更好了。

所有经验、方法、建议，在下一律欢迎，还请各位不吝赐教，我实在是头都大了

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 00:36 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 1. 对"有的目录文件显示，有的不显示的"疑问
具体到一个目录下的文件是可以控制显示与不显示，但是对目录而言不适合做这样的控制。为什么？假如用户只对 1.1.1 目录有访问权限，那么 1.1 的目录级别要不要体现出来？如果只列用户有权限的目录，那怎么能看得出是 1.1.1 的那个目录？

2.组与用户
你的应用实际上是动态责任确定的应用，在程序规划与实施阶段没有办法获知有哪些角色能操作哪些对象;
另外，权限设计不可过于复杂，否则管理员也会弄不清自己分配的权限是什么样的，最少我自己加个两三层的东东就会头晕。
因此我建议你做基于 ACL 的控制。你提到了想使用组的概念，但是你想为一个人也定义一个组，我认为没有必要，完全可以是用户(User)与 Subject(Folder|Documents)直接对应。如果只能有一个人操作一个目录的文件修改，那你直接授权给某个人，和修改 Role-User Map 关系的维护量没有多大的差别。但是如果对一个目录同一种 Permission 的操作分别授权给不同的用户，维护起来肯定没有建个组或一个角色来得简单。

因此，我的选择是直接使用 Subject,Group,User 的三级关系。
这里先解释几个名词:
Subject: 各种目录，文件等对象
Group: 用户集合
User:用户
Operation: 对 Subject 的某种具体操作，如 Visit,Modify,Delete 等
Permission: 是 Subject 与 Operation 的组合，如：指对某个目录的Visit操作

OK, 那让我们来建几个表吧:
Permissions_Table(
subject varchar(20),--对应目录或文件的ID
user_name varchar(10), -- USER-Subject ACL
group_name varchar(10), -- Group -Subject ACL
operation_type int, --1:visit,2:modify 4:delete,3:visit+modify,5:delete+visit,6:delete+modify,7:visit+modify+delete
subject_type int, --1:dir,2:document
)

user_group_table(
user_name varchar(10),
group_name varchar(10),
primary key(user_name,group_name)
)

再下面....
我相信你有能力做完的....

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 10:02 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 感谢iceant，你的意见给了我一个思路，某些地方我确实走入了歧途，也盲目的想设计一个通用的东东（估计这就是过度设计）

不过我还想请教一下就是，对于控制到字段的权限模式你能否也提供一点建议呢

我现在就是想多找些人，听一下别人的意见，然后再自己综合一下，希望能够尽量好的实现这套权限管理功能

希望各位多多发言，希望能对我这已经困累欲绝的大脑来点刺激

再次感谢iceant，jdon的讨论风气是我转的几个论坛中最好的一个了

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 11:16 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 "对于控制到字段的权限模式你能否也提供一点建议呢"

什么叫控制到字段的权限模式?

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 12:19 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 > "对于控制到字段的权限模式你能否也提供一点建议呢"
>
> 什么叫控制到字段的权限模式?

就是对于某个表中的某些字段是可以显示的，而某些是不显示的

当然有个方法是将所有的表的字段及相关的描述信息放到一个数据字典表中，然后对数据字典进行一些相关的赋权操作，不过这样作要求数据字典和所有的表的字段同步

不过总感觉这种方法并不是太好，不过我也没想到其他的方法

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 12:29 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 能不能详细说说你的应用情景? 举个例子

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 13:41 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 > 能不能详细说说你的应用情景? 举个例子

用户、单位等信息存储在LDAP中，而且是远程的，我的系统虽说取的是LDAP中的用户、单位信息，可是还得提供额外的用户、单位增加功能，也就是说在读取用户、单位信息时要将LDAP中的信息与自己增加的用户、单位信息汇合，重新进行树状排列（这个地方采取生成XML树的方式，不知效果如何），与此同时还要判断当前用户的权限，以便控制各节点是否显示（这些节点可能是单位，也可能是个人）。

然后对各个节点显示的信息还得读取控制权限，那些信息可以显示，那些不能显示，另外对各个信息的操作权限也有控制，对某条信息是增、删、改，还是仅仅查看。而对于某条记录的详细信息，又需控制某个字段是否显示，等等等等，如此这般

我的初步构想：
划分功能点：功能模块（不同用户有不同的操作模块，如我们一般程序顶的菜单项，非LDAP和相关信息）、表结构（数据字典表，控制到字段权限时用）
操作（operate）：增、删、改、查看
角色：赋功能模块，及相关操作
用户：赋角色
组：赋用户

算了，就说这点吧，我也晕了，现在思路很乱

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 13:54 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 我的感觉是你对需求不明确，建义你回去和客户坐下来谈谈他们想要的东东。你可以把操作的界面画出来，然后问问客户是不是想这样操作，如果不是，怎么改动，最后要一个需求更改说明书(可能要你写，客户签字，这也是对你自己的一种保护!)，说明确定下来的需求是什么。

所谓有的字段显示，有的字段不显示，多数情况下在程序设计与实施阶段都可以确定的，字段显示就表明用户拥有某种权限，如拥有了增删改员工信息权限的用户，就能看到 Submit 按钮，而一般用户就看不到这个按钮。

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 14:23 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 呵呵，不是submit，那些倒是好说：）
例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而乙可能就是看到b、d、c等项了，是这么个意思

另：iceant你好像一直挂在坛里啊

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 15:11 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 >>呵呵，不是submit，那些倒是好说：）
>>例如显示页面中，有a、b、c、d等项，甲进入后可能会看到a、b项，而
>>乙可能就是看到b、d、c等项了，是这么个意思

所以我请你举个例子来看看啊，不能实际把应用说清楚，就表示没有理解需求，没有理解需求，是不可能做出东西来的。即使做出来了，也只是不符合用户需求的东西。

这里你可以思考一下，为什么甲进入后看到的是 a,b? 是因为甲拥有了某种权限？是甲拥有了某种身份？乙需要拥有什么样的权限或身份才能看到b,d,c?

我觉得你总在说自己头痛，但并不知道自己为什么头痛。

>>另：iceant你好像一直挂在坛里啊

我今天放自己假，不想做事，所以有空。有时忙起来，可能一两个月也不会上网了~~~

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月22日 16:28 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 其实，我真正头疼的是，我在考虑这个系统的设计的时候，思路老是飘到：如果这个系统更加通用的话该如何设计呢。以设计一个通用的，复用性强的系统为己任，头不疼才怪呢

是时候放弃这种想法了，都是让那帮老是让那帮高人把我害的^_^

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月23日 12:37 回复 anonymous 发表文章: 0/ 注册时间: 我的项目中也碰到了类似的问题，即对于每个模块，对其下的各种资源的操作都是一种权限，比如新闻模块，“新闻”是一个资源，而“发布新闻”则是一个操作，而对“新闻的发布”则成了权限
在实际中，新闻若分部门，则“发布A部门的新闻”是一个实际的权限，在权限系统中，将个权限赋给某个角色即可，后面的都好办（参看本论坛中关于权限设计中的RBAC方面的讨论）

所以系统中比一般的RBAC多了以下表：
Resource
Operation

角色除了和权限对应外，还和资源实例对应，即如是A部门的则有RA角色，B的是RB，将这些角色分配给对应的用户或组后即完成授权。

在权限验证的时候通过当前用户和当前可操作角色（由当前模块所对应的资源实例来确定）来验证，ACL.checkPermission(user,resource,operation)

但难点在于模块和资源是变化的，新闻也许只需要一个部门ID就可以确定当前角色，对于复杂的应用如何获取当前模块资源实例并获取当前可操作角色则还没想出好的解决办法

继续thinking...

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月23日 15:42 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 唉，我的问题与此类似，不过又稍微复杂了点

不知可否给我发个这方面的示例图啊，当然是非机密的
也好让我研究研究

以前自己写代码感觉挺爽的，再难的方法也都可以实现，可现在自己作设计，可真是感觉晕头转向的啊:(

努力、奋斗

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月24日 16:24 回复 littlebird 发表文章: 1/ 注册时间: 2003年10月24日 16:03 看了这么多关于权限方面的讨论真是受益匪浅。
这里说说我的想法：
我认为对于多数企业应用项目，相对而言都不是很大的项目，权限管理部分是不是可以简化成：user *-->1 role 1-->* operate
用户可能有很多组织上的层次关系，但在这里可以将它压平，不论什么层次都直接和角色相关，而且只有一个角色
权限也可能有很多层次关系（比如新闻包括A、B或C部门的），这里也把它展开，让角色直接最底层的权限相关（如A部门新闻的修改权限）
根据用户获得它的角色，再根据角色获得它拥有权限的集合。

而group是用户的集合，把它加上会变得相当复杂；当然还可以有权限集合的概念也加入，那就更复杂了。

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月25日 11:07 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 我想理一理思路，看看 ACL 与 RBAC 的区别:

还是以部门新闻来讨论，对于静态授权，在系统设计做需求分析的时候，往往就可以
确定一个系统角色的种类，像新闻系统中，根据需求，可能会有新闻发布者(Publisher)，
新闻审核者(Reviewer)，新闻浏览者(Visitor)，管理员(Manager)以及超级管理员(Administrator)。

在设计的时候我们也已经把这些角色与相应的一些 Operation 绑定在一起。
如：Publisher 拥有 Publish_Operation + Modify_Operation
Reviewer 拥有 Review_Operation + Modify_Operation + Delete_Operation
Visitor 拥有 Visit_Operation,
Manager 拥有 Create_News_System_Instance_Operation +
Modify_News_System_Instance_Operation +
Delete_News_System_Instance_Operation
Administrator 负责 Create_User_Operation+
Delete_User_Operation+
Assign_Permission_Operation+
Deassign_Permission_Operation +
Assign_Role_Operation+
Deassign_Role_Operation

在授权时，往往先为一个用户(USER)，赋予一个角色，如: Manager. 这样，USER 就
拥有了对所有 News_Instance(也就是部门新闻) 操作的权限。
现在假设用户(UserA)访问 Create_News_System_Instance 功能来创建一个新的新闻实例，
叫做 采购部门新闻. 因为我们在设计的时候就确定，该功能只能由 Manager 来访问，
于是，系统中权限的判断部分会首先判断当前用户(UserA)是否 Manager 角色，是的话就允许
访问，否则显示没有授权的错误信息。

所以，对于 Manager 这样的应用:
[1] 在设计的时候，我们就将这样的角色与相应的 Permissions(A list of Subject-Operation pairs)
关联在一起了，这里的 Subject 是所有的新闻实例(News_Instance),Operation
就是 Create,Modify以及 Delete.
[2] 在授权的时候，超级管理员(Administrator)可以利用 Assign_Role_Operation 将用户(User)
与 Manager 这个角色关联起来。这样，User 就拥有了对所有新闻实例的 Create, Modify 以及 Delete
操作的权限。
[3] 在权限判断的时候，RBAC 系统首先判断当前用户是否是设计时确定的角色(这里是Manager),
如果是，就允许用户访问，否则就拒绝访问，并显示错误信息。


对于 Publisher 这样的角色有些不同，Publisher 这个角色只与 Operation 绑定在一起，并没有与
具体的 Subject 相关联，因此，在授权的时候，还需要指定相应的 Subject.

所以，对 Publisher 这样只能事先确定 Operation 的应用来说:
[1] 在设计的时候，我们只能确定该角色能进行哪些操作，而不能确定这些操作实施的对象。
[2] 在授权的时候:
[2.1] 首先将 Publisher 与 Subject 关联,如将 Publisher 与采购部门新闻关联产生:
采购部门新闻_News_Publisher 的角色
[2.2] Administrator 为用户(User)授于 采购部门新闻_News_Publisher 角色。从而 User
拥有了对"采购部门新闻"的发布权限
[3] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation, 系统首先判断
该用户是否 采购部门新闻_News_Publisher?如果是，就允许用户访问，否则就拒绝访问，
并显示错误信息。
这里用到的方法可能是这个样子:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
List publishers = RBAC.findRole(new Permission(采购部门新闻,Publish_Operation));
if(publishers==null) return false;
for(Iterator it = publishers.iterator; it.hasNext();){
Role publisher = (Publisher)it.next();
if(publisher.isAssignedWithUser(User)){
return ture;
}
}
return false;
}

假如说，不采用 RBAC 的做法，考虑一下，使用 ACL，那又会是什么样子呢?
对于 Manager 那样能在设计时就确定 Subject 与 Operation 的角色，我认为没有必要考虑 ACL 了.
对于 Publisher 这样，只能事先确定 Operation 的角色，我们来做个对比.
权限系统要灵活，但是也要简洁，要不然就很可能导至失控。因为嵌套的层次太多，有可能发生不可
预知的情况. 有一天管理员可能会莫明的发现，怎么这个人会有这个权限的?
所以，我认为在 RBAC 里不支持 Role 的层级关系为妙。

好了，现在来看看 ACL 对 Publisher 应用
这里指的 ACL 是直接将 User 或 Group 与 Subject 关联的做法。
User 与 Subject 是多对多的情况，
Group 与 Subject 也是多对多的情况，
同样的，User 与 Group 也是多对多的情况。

现在，还是以采购部门新闻为例:
[1] 在授权的时候，可以有以下操作:
[1.1] 将 User 与 Subject 关联在一起,但是要指定相应的 Operation.
如: assignPermission(采购部门新闻,Publish_Operation,User)
[1.2] 将 Group 与 Subject 关联在一起:
如: assignPermission(采购部门新闻,Publish_Operation,Group)
[1.3] 将 User 与 Group 关联
如:
assignUserGroup(User,Group)

[2] 在权限判断的时候，用户访问 采购部门新闻_News_Publish_Operation，系统做如下检查:
boolean checkPermission(采购部门新闻,Publish_Operation,User){
boolean hasPermission = false;
// users include:
// 1. Permission direct assigned Users
// 2. The user assigned with the groups that assigned with permission
List users = getAssignedUsers(new Permission(采购部门新闻,Publish_Operation));
hasPermission=users.contains(User)?true:false;
}

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月26日 22:32 回复 GreateWei 发表文章: 3/ 注册时间: 2003年07月03日 16:35 曾看过ofbiz关于权限设计的相关资料，感觉ofbiz在实现方面有很大的通用性。看过之后，总觉得自己理解的不够透彻，希望大家能详细的讲解一下，谢谢。

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月28日 10:30 回复 qlwangbj 发表文章: 5/ 注册时间: 2003年09月25日 12:20 RBAC是什么意思，是哪几个词的缩写？

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月28日 11:30 回复 浆糊 发表文章: 246/ 注册时间: 2002年08月06日 19:20 role based access control

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月28日 15:32 回复 SUPERMY 发表文章: 24/ 注册时间: 2002年10月21日 20:10 可以试一试tiles,应该很简单的。用户权限必须在配置文件中写死。

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年10月29日 23:26 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 > 可以试一试tiles,应该很简单的。用户权限必须在配置文件中
> 此馈?

呵呵，你说的跟上面讨论的可不是一个概念噢，这些权限是无论如何不能写死的。

没想到几天没来，这个帖子居然让banq提到首页了，乐

感谢各位的指点，我已经将这套系统的大概框架画出来了（具体实现还得等一阵^_^），首先感谢iceant，他的回复很大地扩展了我的思路，我在其它相关帖子中发现了iceant的大量发言，看来iceant是作新闻系统的啊，很多例子中举到了：）

不过，上述的讨论并不能完全套用的我的这个系统中，不知各位看明白我的提问了吗（没看明白？看来我还得好好进修一下语文-_-），在我的系统中不光有功能模块的划分（或说是功能点，显得更细），这方面的权限管理相对比较简单，不管怎样，只需将权限控制到功能点即可，也可以使用角色、组等方便配置。

而在我的这个系统中，有一个很重要的要求就是，信息权限的管理，也就是说权限要划分到某个功能点下的某条具体的信息上去，也就是说，一条信息刚录入到系统中，管理员要对其进行权限控制，那些人或那些组织或那些自定义组成员可以看到该信息，并分别可对该信息拥有什么样的权限（增删改等），当然，绝大多数用户只能拥有浏览的权限，但是在浏览权限方面又有控制，那些用户（或组织、或自定义组）可以看到哪些字段内容是不一样的，这就比较复杂了。

我后来的解决思路是：
对模块（或曰功能点）划分角色，同时对角色赋一些初始权限，这个初始权限主要是针对管理员的，也就是说初始对管理员赋所有权限，一个用户只拥有一个角色。
为了便于信息权限的控制，使用了自定义组的方式，将那些具有相同信息操作权限的人员划分到一个组中。将信息权限（包括字段权限控制）单独进行控制，也就是说除了管理员的初始权限外，这部分的权限控制不再与角色发生关系，而是由管理员对每条记录（当然可以批量操作）指定权限，权限控制到个人、组织和自定义组，在同时也将字段权限进行划分，按照一定的字符规则存储到数据库中去。
不过这样做之后，所谓通用性嘛，就不考虑了

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月01日 10:02 回复 agilejava 发表文章: 64/ 注册时间: 2003年11月01日 09:33 最近，头儿也要我们做一个权限管理方面的通过系统，真是无从下手!

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月01日 21:28 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 这个东东想搞个通用的确实很难，就像openAcl，我就基本没法拿过来用，不过实现的思想倒是可以好好研究的。
我打算把我这个东东实现之后，看看能不能提取出来

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月01日 21:32 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 > 这个东东想搞个通用的确实很难，就像openAcl，我就基本没?> 拿过来用，不过实现的思想倒是可以好好研究的。
> 我打算把我这个东东实现之后，看看能不能提取出来

不好意思，写错了，应该是pow2acl

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月01日 21:46 回复 racer 发表文章: 1/ 注册时间: 2003年11月01日 21:05 不好实现啊，想想一个修改操作包括n个字段,那就要分解成n个操作。控制要求高效，分配要求能做到友好，难啊。

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月02日 00:33 回复 冰云 发表文章: 2/ 注册时间: 2003年11月02日 00:17 我是新来的~~~ 第一次发言：〉俺是初学，献丑了

User Group Permission Subject Operation
前面iceant提到了这几个表，
其中Operation对应于Subejct的操作
如Modify,Delete等等

我想，是否可以再增加2个，如Column与ColumnVisible这两个表(或类)
Column: id,table,column_name,aliasvalue
ColumnVisible:格式类似于 1-1010101010这样，表示id为1的表列可见与否，这就相当于Group，就像将Subject与Operation重新细化并关注
于不同的层面，即更微观的部分 其他的就类似啦

每个User可以持有一个或多个ColumnVisible属性
根据该属性来判断该用户在某条信息中，能够看到什么东西
同时与Operation进行检测，该用户可以拥有Delete等
但View与Modify等，仅能够操作他可以处理的列

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月02日 09:59 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 权限系统确实是可大可小的系统，很难说有一个通用的。

有时我的客户说只要最简单的 User -> Subject ACL 控制就可以了，但是有时又提出更复杂的要求....

因为公司整个内联网的应用框架是我一个人在规划，所以，我可以设计出一套在公司内, 应用之间比较通用的模型(还在设计规划过程中，也许明年初我会实现它)。

在我现在的模型中，除了上面的 Subject,User,Role,Group,Permission,Operation 这些概念外，还有 Scope 和 Appointment
我引入 Scope 这个概念，就是为了做到比较通用，因为 上面的 Subject,User,Role,Group,Permission, Operation 等等，都是在一定空间内存在的。拿 Domain 来举例，例如: domainA/UserA 是在 domainA 内的用户, domainB/UserA 是在 domainB 内的用户， 这两个域中都有叫 UserA 的用户，但是他们所指向的人确是不同的，这里就需要引入 Scope 的概念，除了 User, 其它的 Object 都是在一定 Scope 内存在的，超出一定的 Scope, 同样叫做 UserA 的人就是不同的人，他们拥有的权限可能就不一样了。

Appointment 在我的设计中，主要是面向时限控制的，例如在 workflow 这样的系统中，有时一个 manager 要出差，在公司外面因为各种原因不方便做审批，但是公司运作不能因此而停滞了，所以需要由 manager 授权给一位员工，如一位 leader, 但是这样的授权需要有个时限，如 manager 需要出差两个星期，这两个星期内的审批权，他可以转授给 leader, 所以，一个 appointment 可能包括了 assigner,receiver,time_period[from,to], subject, operation....


这样，当 leader 在对 subject 使用 operation 时，系统就会判断它是否是 receiver, 还有，操作的 time_period 是否有效等等~~

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月07日 18:05 回复 javaw 发表文章: 6/ 注册时间: 2003年10月29日 13:46 我觉得权限系统最根本的就是理顺几个重要实体的ER关系就ok了，具体用什么形式实现你的权限系统设计，方式可以千差万别，我们就曾经在j2ee的系统里面用pb做了一个权限系统（时间紧迫），也不错。？？？

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月08日 22:29 回复 lee_sure 发表文章: 1/ 注册时间: 2003年11月08日 22:21 第一次发言，没有好话，先泼点水。
我实现过一个类似复杂的权限管理系统，用B/S结构。用户用了半年后，我不得不改得简单了。原因是用户根本不会使用这个复杂的授权系统。半年内的授权工作都我们工程师做的。悲哀！
先提醒一下，用户经常是放大自己的能力的。用户真的需要如此复杂的权限管理吗？我对此表示怀疑。


Lee S

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月09日 10:00 回复 iceant 发表文章: 462/ 注册时间: 2002年10月13日 22:32 TO: Lee_sure

你说的很对，用户提出需求的时候往往是天马行空，这充分体现了人类思想的伟大。

不过对于我们这些工程师来说，如果不能很好的控制需求，那只能任由客户拖着到处跑，最后累的往往就是自己。

我现在的做法是要求客户提供需求说明书，字数多少，详尽与否我不在乎，我只是想通过这个环节让用户想清楚他到底需要什么。这样的做法实行了半年多，从实效来看，大部分的用户都能理解，但是，还有一些不尽如人意的地方，因为我发现有些客户提供的需求还是很简单，没有实质的改进，像是没有想过一样，对于这样的需求，往往在收到需求说明书后，我会再写一份比较详尽的，然后再让用户看看是否是他所要求的。这样一来需求确定的周期肯定会变长，所以，下一步我打算起草一份需求规范，让用户在写需求时照着写。

 

Re: 我也请教一个关于权限设计方面的问题 发表: 2003年11月12日 11:01 回复 ninsky 发表文章: 25/ 注册时间: 2003年10月21日 22:00 TO：iceant
你的这个方式我也在用，不过我的方法是根据客户的需求出一份需求说明，然后让其签字，不过感觉此种方法少了些许的交互，感觉你的方式效果应该更好，不过这里面又牵扯到一个问题，可能用户根本就不愿意自己写这个说明书（可能他自己都不知道需求是什么），而且对于小系统还好说，对于较大规模 的系统，一个需求可能牵扯到n个人，这时候再让用户出说明书，好像有点不太现实了

不过，根据不同情况，还是让我们灵活变通吧
另外，你的那个规范文档要是出来的话，还希望能共享阿：） Re: 我也请教一个关于权限设计方面的问题 发表: 2003年12月08日 12:00 回复 将你所谓一个表对应到多个Subject，不知可否解决你的问题？ loreal

发表文章: 2
注册时间: 2004年01月07日 15:43 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年01月07日 16:15 回复 我认为可以使用带参数的操作来解决这个问题。

基本上还是基于RBAC模型，可以对其稍微改进一下：对用户也可以单独授权。其实可以将单个用户、组或者角色都统一看待为subject（主体），将所有资源统一看待为object（客体），然后再加上带参数的操作(operation或activity），这样三元组（s，o，a）就表示了s对o所具有的a操作权限。

我们对（s，o，a）再进行一下扩充（s，o，a，c），c表示condition，即
约束条件。（s，o，a，c）表示s在c条件下对o有a操作的权限。

这样就很容易解决许多问题：
授权的时候将每个用户/组/角色的权限按上述四元组表示清楚即可。用户提出访问请求时，除了查看是否有与用户请求相匹配的四元组，还要看条件是否满足，条件满足的情况下，就允许用户访问；反之，拒绝。

关于对表字段的访问控制，我认为如果你设计的资源管理模块能细化到字段级，那么对字段级的访问控制也就不成问题了。 iceant

发表文章: 462
注册时间: 2002年10月13日 22:32 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年01月08日 00:25 回复 TO: loreal

agree with you wqy518

发表文章: 5
注册时间: 2004年01月19日 10:54 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年01月19日 11:19 回复 四元组的抽象确实很精彩！！！
权限管理中一个很重要的东西就是客体对象的粒度大小问题，如果粒度过大，则分配操作简单，但系统功能就弱了；如果粒度过小，系统很灵活，但配置非常复杂，不但开发工作量大，而且可能根本没法用。
以普通的数据库应用为例，一般控制表一级的访问即可以了，这是客体对象的基本粒度为： 表×表操作（增删改，为说明问题，直接把操作也当作对象一部分），象楼主提到的系统，基本粒度为：表×字段×记录×操作，这个量级是不得了的，再加上用户，组，权限，复杂度非常可以了。
soloist

发表文章: 4
注册时间: 2003年03月27日 07:51 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年02月06日 10:45 回复 这样，修改权限是不是很麻烦呢>？ hexianmao

发表文章: 2
注册时间: 2004年02月11日 20:28 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年02月11日 20:31 回复 333 hexianmao

发表文章: 2
注册时间: 2004年02月11日 20:28 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年02月11日 20:31 回复 444 kewan

发表文章: 46
注册时间: 2003年04月20日 19:11 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年02月16日 03:50 回复 这是应用AOP的一个非常好的例子！
所有的有关权限的的操作都是一个cross-cut，把权限操作从代码中解偶，非常漂亮!如果想换一种权限机制，也非常的方便。 daquan198163

发表文章: 142
注册时间: 2003年08月19日 10:56 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年02月16日 09:35 回复 > "对于控制到字段的权限模式你能否也提供一点建议呢"
>
> 什么叫控制到字段的权限模式?
其实“控制到字段的权限模式”并没有太大的必要，倒是有一个和它类似的需求：用过TestTrack（一种测试工具）的人一定对过滤器很熟悉吧，我觉得这个东西很有用。 tjj36

发表文章: 1
注册时间: 2004年11月15日 15:55 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年11月19日 10:51 回复 我是新来：）
看到这么多人的观点和见解，受益非浅。
尤其　iceant 　让偶茅塞顿开!
努学习！
天天向上！

vtrtbb

发表文章: 3
注册时间: 2004年12月17日 09:14 Re: 我也请教一个关于权限设计方面的问题 发表: 2004年12月17日 09:18 回复 问题：上面所说的权限设计只能作到粗粒级的控制，无非也就是显示不显示的问题。

但我想实现这样的功能：部门经理可以看到本部门的所有订单数据
员工A可以看到自己的订单数据，而不能看到其他的人数据，而总经理可以看到全部的数据


该如何设计？ myy

发表文章: 9
注册时间: 2005年01月21日 22:05 Re: 我也请教一个关于权限设计方面的问题 发表: 2005年02月05日 08:17 回复 （s，o，a，c）四元组，说白了，SQL的 select 语句就是活生生的例子。
banq

发表文章: 7953
注册时间: 2002年08月03日 17:08 Re: 我也请教一个关于权限设计方面的问题 发表: 2005年09月26日 09:38 回复 相关讨论：
http://www.jdon.com/jive/thread.jsp?forum=46&thread=13450 qchy790609

发表文章: 1
注册时间: 2006年08月04日 15:54 Re: 我也请教一个关于权限设计方面的问题 发表: 2006年08月04日 15:58 回复 你所说的是不是数据权限的问题,最近我也遇到了,而且是要做一个系统的过滤器,比较麻烦,你现在有设计思路了吗 imlsq

发表文章: 4
注册时间: 2006年08月24日 18:29 基于JAVA的权限系统设计与实现 发表: 2007年04月02日 09:24 回复 这个网站有一篇非常不错的权限设计的说明和实现，是基于JAVA的

http://www.yido8.com/indexhtml/2007-03/4028813c1167bdd40111690e0a650014.html

http://www.yido8.com/

基于JAVA的权限系统设计与实现
本文档告诉大家怎样去设计一个轻量级的基于方法级别的权限控制系统。文档分为2部分，第一部分为权限系统理论分析，第二部分为用JAVA实现的一个通用权限系统模型，最后用一个简单的实例演示了这个权限控制模型的效果。


基于J2EE的权限系统设计与实现.. 1
1本文的读者对象.. 1
2联系作者.. 1
3权限系统目标.. 1
4权限系统说明.. 2
4.1 权限系统对象.. 2
4.2系统对象之间的关系.. 3
5权限系统功能.. 4
5.1权限系统维护管理.. 4
5.2权限验证控制.. 5
6权限系统JAVA设计与实现.. 7
6.1权限系统模型.. 7
6.2权限分配和管理.. 10
6.3方法级的权限验证实现.. 10
6.4权限控制过程实例.. 12
7编后.. 18
didiluck

发表文章: 2
注册时间: 2007年04月04日 14:49 re:我也请教一个关于权限设计方面的问题 发表: 2007年04月09日 09:45 回复 我比较喜欢 用户--角色--具体操作 这样的权限管理,操作起来也方便一些.
一个用户可以同时身兼多个角色,在进行权限管理的时候,操作的是角色.
同时将角色和功能模块结合... catiga

发表文章: 1
注册时间: 2007年04月28日 13:15 re:我也请教一个关于权限设计方面的问题 发表: 2007年04月28日 13:19 回复 简单说说我的看法
个人认为你关于权限的解决方案不适合系统，仅仅适合使用在网站上面。
对于应用系统的开发，权限是很重要的一层，重要的一点是要与系统应用的组织机构的集成，通常，我们会采用一些成熟的解决方案来设计权限系统。比如RBAC是一种很好的权限系统模型，并且开放性很好，很容易集成组织机构，借助于简单的UML工具很容易理清权限系统的PO和BO以及service层的关系。