关于权限系统和组织结构

有一个系统权限系统需要设计一下,但是小弟太菜,不知道怎么下手,往大家指点一二
大致的组织结构如下所示:

关于管理员:整个系统(包含多个org)有一个管理员,可以管理整个系统的权限管理;每个Org有自己的管理员,但是只能管理本Org的权限;注意:管理员只能管理权限,但是没有查看数据的权限,比如管理员最多只能看到有一个文件没有处理,但是是不能浏览文件的内容和要素的

一些特殊的地方:
(1)每个组织或部门都有自己的领导,领导可以给普通用户授权(这就包括前面有帖子提到的比如出差代处理),而具体的权限由管理员设定并不超过领导自身具有的权限
(2)不同的Org的用户和部门是允许重复的,就是Org1和Org2里面允许有完全一样的ID(如果用ID唯一表示用户的话)的用户,这一点只是用户提出来的,如果不说服用户改变的话,该如何的考虑
(3)用户可以在不同的Dep和Org之间调动
(4)用户可以看到的资源的多少和用户的级别没有关系,比如高级别的领导不能看很多细节,如对于一个审批的处理,主理的人员可以查看办理的全程资料,而领导可能看入口(从哪儿来)和结果;这是针对办理过程而言
(5)从具体数据的角度,领导不关心细节;比如一份通知,办理人员需要看到通知的级别(是否加密)、没一步的发送时间,但是领导只看内容;与(4)略不同,这是针对具体的要素,个人觉得这一点不放到权限系统,放到具体实现逻辑比较的合适
(6)用户限制的硬绑定(比如可以限制IP、MAC),我觉得这点应该比较容易实现,都是一些开关控制;但是我有些担心用户以后会提出把这一点和权限绑定,那么就麻烦多了

扩展:可能不同的org的数据都是分布的,但是对用户而言是透明的,如同操作一台数据服务器

能否找到稍微通用一点的权限系统的设置,望各位不吝指点一二

顶一下,希望看到好的思路。

可不可以对你的“权限”这个概念分为“功能权限”和“数据权限”,比如管理员对数据的维护,他不需要了解所要维护的数据的详细信息,可以进行类似添加、删除、指定管理员等操作,这样的权限姑且称为“功能权限”,而用户对某一详细资料的操作比如阅读、修改、审批等需要的权限作为“数据权限”,把“功能权限”和“数据权限”进行分别管理。

这个是当然可以的

因为做办公自动化比较多。也经常考虑这些问题。
我想,人员可以单纯些,只是作为一个人员数据的存放。
部门、组织、角色、职务包含人员信息,权限的划分根据这些来进行组织。

而画出的如上的树可以根据这些组织信息来划分。

而我思考的还有,其实所谓的部门、组织、角色都是一个人员的划分而已,实际上用一种结构就可以描述。只是在提供用户的表现形式上再划分成多种形式。

学习

期待更多的回复

用户的本身的ID跟数据库中标志的ID是不一样的.如果具有比较好的可扩展性的用户管理系统的话,最好维护一张用户表.
至于多于权限管理的问题,个人认为可以对于管理的权限进行细分,比如系统管理权限,业务权限等!

支持三楼的想法!
首先将所有的操作都提出来!
建立group,对group进行授权,将允许的操作赋予!
再把用户归属到对应的group中

其他的问题应该相对容易些,只是读取数据时的判断多些就可以了!

象3楼说的那样 “功能权限”和"管理权限"分开,你可以设置角色(具体权限的集合),你可以让管理员只能操作角色(新建角色,给角色授权,吧角色赋给用户 等等),不操作具体的数据,管理给角色授权,管理员可以将某个角色赋给某个用户或者从某个用户删除某个角色,这个用户被赋予这个角色,就拥有这个角色具有的权限,否则,用户就没有相应的权限

又是一个老话提了!顶顶

前一段做的一个系统的权限管理
1、参考Novell系统的文件权限管理(Novell系统现在已经很少人用了,我还一直怀念)。引入了组的概念(也可以称为岗位吧)。
2、将一个柜员的权限分为两种。1、可授权限,就是可以授给别人或岗位的权限。2、功能权限,自己可以操作的功能。
3、每一个柜员都有登陆控制,考虑由网卡,Ip,登陆次数,密码等。
4、柜员对访问数据的控制。可以访问哪些基本的数据,哪些部门的数据,已及对数据都可以做什么操作。
凡是可以分类的数据都可以在这里控制。
功能权限:主要解决了一个柜员可以做哪些工作。
数据控制:主要解决了一个柜员工作是可以操作那个部门的数据,那个级别的数据
5、从系统运行的实践来看,基本可以满足需要。上线以后增加了柜员权限的拷贝功能。

另外提醒:
建立组的概论是正确的,但切不可将柜员的权限都从组来获的。因为往往两个部门同样的岗位,但在功能要求上会有小小的不太。可能会因为这小小的不同你就要再设一个岗位。所以给柜员不但可以继承组的权限,也可以扩展一些自己的权限

Sorry I can only type English from my employer's PC.

I suggest using a separate database to maintain "权限管理" policies. "管理员" can maintain the whole database; "领导" maintains the policy data of his department. Authorization is done by a service that inquires this database. It is separated from the business logic thus it can be changed anytime. Also you can define very complicated policies with a program language.

The drawback is that the whole system will not work if the policy inquiry service is down. What's more important is how to implement the whole system in a secure way.

Actually I think this is generic enough to start a new JDon project:) BEA has a product called WebLogic Enterprise Security, I guess it provides more commercial functions.

本人比较菜,个人看法:
1.对这种结构和权限,直接建立,部门表(树性,保存父节点id),人员表,角色表,功能权限表和数据权限表,角色权限关联表.如果有其他职务再建立职务表.
2.
在分配权限过程中,先建立角色,给该角色分配两种权限,再给用户分配角色,对权限得控制分后台(数据权限)和前台(功能权限).

请教一下.前台功能权限是不是指用户执行操作的权限;后台数据权限是不是指用户存取操作系统文件和数据库数据的权限?