关于权限设计的探讨（寻求数据库设计者和开发人员的帮助）

Question

我做过的一个mis 只是db设计了一个login表 
主要字段是
loginid lodept lo       lorole          effet_or   password
0001 10001 40 sys admin  1 xxx用户的权限是在前台做的，用户登陆时先去查数据库的login表，取得相应权限，然后用户根据不同菜单区分权限进行操作，前台可以有个菜单权限管理(只有sys admin才能操作)，根据组别设置菜单权限，或根据菜单设置组别权限

Answer 1

权限设计需求：
1、用以实现对界面对象（如菜单、按钮）的权限控制。简称对象级权限
2、用以实现对数据能否被某一个用户修改、删除的权限控制。建成数据级权限对象级权限基本上大家都实现过，数据级权限比较特殊，它能够实现数据的权限分配
例如：A用户可以将其产生的数据分配给B用户修改，给C用户删除的权限。数据级权限的要点就是要在表中增加一个字段用以保存数据所有者的用户标识。

Answer 2

数据级权限的管理和对象权限有比较大的区别，它不容易使用一条语句精确的描述，Notes的做法是保存每个文档的所有者标识，在关系型数据库中也可以使用相同（或者类似）的办法解决，但情况要复杂一些。如果要实现对单条数据的存取控制，恐怕只能用流程来实现，这种手段在OA系统中比较常见，比如将A写的某个公文文档移交给B审批，这时B获得的只是对所有者A某一个而不是所有文档的审批权限。虽然也是赋予了B某种权限，但事实上这不属于上文所讨论的权限管理范围，而只是业务流程。但是我们考虑，在非公文流程的大部分系统中，只是简单的设定：用户B具有对所有者A的文档具有修改权限，而这种定义，是可以在上文描述的数据库进行描述并实现的。事实上，在关系型数据库中，要对某个用户对表的存取权限精确到记录是不可能的，这只能在程序中使用聪明巧妙或者笨办法解决，当然，与之相关的是业务流程的设计。很多OA系统自称能自定义流程，大体也就是能通过巧妙的数据库设计，将流程运作的全过程记录在数据库中。基于Lotus的OA系统理论上可以定义某个用户对某个文档的存取权限，但实际操作中，为了减轻开发人员的负担，都只是定义了角色对某个数据库的存取权限，而将剩下的内容交由前端控制，这和我们在ASP程序中习惯使用SA登录SQL Server是一样的。业务流程的实现方法本质上和操作权限无关，它将是另外一个讨论话题。以上只是个人浅见，请大家批评指正！

Answer 3

blueluhan(鹿寒),要对某个用户对表的存取权限精确到记录是可能的，请发表你的高见！

Answer 4

我还没有想出好办法来，我想如果要记录某个用户对单条记录的存取权限，恐怕得象日志表的记录那么复杂
如果可以用流程之类的办法解决，那是最好了当然，我的经验有限，如果 blueluhan(鹿寒) 兄有更好的办法，欢迎一起讨论！

Answer 5

我说一个与数据库无关的安全解决方案
我是一个比较喜欢偷懒的人，写过一套类似于楼主所说的权限系统，但是发觉在用户组的权限继承方面存在一个极大的麻烦，而当用户同时属于两个组的时候，权限的交集计算非常麻烦。还有权限的委派和用户权限的临时提升也是一个很烦人的事情。于是就放弃了那套系统。
我发觉Windows2000的AD权限系统非常不错，于是动起了这个脑筋，最后发掘“组策略”可以实现我的想法。组策略支持继承和权限交集，而且使用也非常方便。于是研究了一下其2次开发原理，使用了注册表策略实现了我公司MIS系统的权限，可以控制到任意应用程序角度（完全取决于软件开发者），而且配置相当方便（使用AD的用户、用户组管理器）。
其实AD的注册表策略非常简单，充其量就是其用户权限的延伸，我们自定义了新的权限。AD负责对其进行管理和计算，然后把最终的结果写入用户计算机的注册表的一个受保护的段内。该内容对于用户只读。对于客户端程序，只需要判断注册表的键值即可。
我很少上CSDN，如果诸位有兴趣研究可以发email给我：[email protected]

Answer 6

很高兴听到 bucher(无人永生) 的设计思路，我已给您发去mail，希望能做进一步的交流

Answer 7

mail我收到了，这几天很忙
过几天我会给你回复的

Answer 8

http://www.peoplewarecn.com/xprogrammer/XProgrammer26.pdf
安全模型的一种模式语言
http://www.peoplewarecn.com/xprogrammer/XProgrammer25.pdf
基于角色访问控制的UML表示供参考