针对于集团应用系统的数据权限控制

针对于集团应用系统的数据权限控制
系统中的组织机构介绍：系统中有多个集团，每个集团下有多个公司以及公司，每个公司下又有多个直属部门和办事处，办事处下面又有多个部门
业务往来关系：1个集团下的公司，分公司相互之间存在业务往来；当然公司下的部门之间，办事处之间，以及办事
处下的部门之间肯定是存在相互业务往来的，比如财务部门要计算工资，必须需要人力资源部的考勤数据和专业部门的奖励惩罚数据等；公司之间的部门
亦可存在相互业务往来，集团部门和各公司部门之间亦存在业务往来，
比如各公司分公司的人力资源部门和集团人力资源
存在业务往来，集团人力资源对集团内的人力资源做整体上的规划，监督，考核执行，而各公司分公司人力资源部门执行各公司的人力资源管理工作，其他专业体
系也具有类似架构；
集团和各公司，分公司存在业务往来； 1个集团和其他多个集团可能存在业务上的往来；集团下的公司，分公司与系统中的其他集团中的公司，
分公司存在业务往来，
比如A集团下的a公司有个工程承包给B集团的b公司负责建设，a公司的对应部门需要对b公司的工程进度，质量等等监督。

根据描述系统中的业务往来就成了一个业务网，业务复杂；而数据权限的控制也是一个头痛的事情：
数据权限通用规则：
对于一般用户来说：
1.有些数据是行业标准，系统中的所有集团中的所有用户多可以查看和维护。
2.有些数据是某个集团内部所有用户都可以查看维护。
3.有些数据是只有某个公司内部的所偶有人可以维护查看。
4.有些数据是只有某个部门下的所有人可以查看维护。
5.还有一些数据只有这个数据的拥有人才可以查看维护。

不同于一般用户的有些特权用户（不管你这个功能的数据权限怎样控制）的权限规则：
1.某些用户可以查看维护集团内的所有数据。
2.某些用户可以查看维护公司内部的所有数据
3.某些用户可以维护查看某个部门的所有数据
4.某些用户可以查看维护其他一些公司，一些部门的数据。
5.有些用户可以维护其他集团中某些公司，某些部门的数据。

这样的数据权限控制系统怎样设计呢？希望有这方面设计经验的朋友建议下。

这里需要补充一点：不同组织机构单元下的相同的角色他们的数据权限可能大相径庭！

评论

13 楼 CshBBrain 2010-12-26  

hustlxjaw 写道

CshBBrain 写道

hustlxjaw 写道

你这样理论上应该是可以实现的，但是通用性不强，稍微发生一点变化很难应对。
如果是我设计数据权限，肯定要求能够灵活管理数据权限组（数据权限的分类依据），然后将数据权限组与功能、角色关联起来。如果数据权限组之间可能也有逻辑关系，这个就需要去定制了；如果数据权限组之间没有逻辑关系，就比较简单了。
另外，SpringSecurity在数据权限控制方面有一个“后拦截”的处理方式，在某种条件下也是可以借鉴的。
上面是我对数据权限的理解，但是暂时还没有时间来整理相关文档，最近在弄报表。。

这位兄台，你所提出得“数据权限组” 以及它和功能，角色之间的关系是否可以说得再详细点以达到通用的目的，还有管理员在设置的时候务必要操作简单，工作量要少，且便于理解。

数据权限组只是将需要划分数据权限的数据的一个分类标准，比如现在有一个数据权限组叫做机构，机构这个数据权限组的内容包括财务部、人力资源部、开发部等。数据权限组只是用来描述数据的划分的，真正的数据权限组下的项才控制数据权限，比如数据都跟财务部、人力资源部产生关系。
通过角色与功能点、数据权限组的管理，可以实现同样的角色，不同功能点具有不同数据权限。

终于明白你的意思了，你的数据权限组大概就是 数据权限复用的一个思想，我先在系统中建好一些数据权限组，并设置好这些权限组的数据权限，再使用数据权限组来给角色或人授予数据权限，以达到减少系统管理员的工作量，这个思想不错，赞一个，谢谢！

12 楼 CshBBrain 2010-12-26  

AngelAndAngel 写道

   你这个问题我曾经也遇到过，我觉得像这种数据权限不能迷信现在的一些所谓的权限框架，只能浪费时间。首先你要的是数据权限控制，而数据权限呢是需要通过菜单权限来体现的，这里面有重合也有不同点。你如你刚才举得例子，如
集团--公司--办事处--部门--个人,有可能这四个域里面的人都有 订单提交历史记录这个菜单权限，那么点击进去呢，会出现各自的数据，比如，集团的域里面需要看到所有集团数据，公司是看到公司所有的数据，办事处，部门，个人以此类推。我们针对这种情况是这样设计的，首先，公司组织部门要设计成树状结构，每个组织（如集团，公司等），在数据库都有自己的部门路径（比如id组成的1,2,3），当然，还得有权限表，用户表，角色表，用户权限表，角色权限表（一般每个人都对应一个角色，而用户权限表是用来给那些特殊人用的，可以在角色权限的基础上多加一些额外的权限）。其次，权限的类别，可以分为，功能模块权限，比如订单管理，用户管理这些大菜单；数据列表权，如上述的订单提交历史；数据操作权（如添加，修改需要的权限）；数据范围权限，控制数据列表的范围的，一般是别的数据列表的子权限，很重要。。下面分类介绍：
  1，功能模块权：很简单，就是属于菜单的权限。就是每棵树的最上级，点击出来也最多是折叠收缩之内的。
  2，数据列表权：重点。比如订单历史列表这样的，点击可得到相应的数据列表的，那怎么得到自己该得到的数据呢，在这个权限下面一般都会有类别为数据范围的子权限，如集团数据，公司数据，办事处数据，部门数据，个人数据这些，添加这类子权限的时候，会让你输入范围，举个例子，假如这个人他只能看到本部门数据，那么可以这样填写范围
@commitUser.deptId=$session_operator.loginUser.deptId。在后台呢，专门设计一个通用的解析这类语句的工具，如把@号可以自动转换成你的数据表的别名(当然，你的订单表中肯定要有commiUser字段啊)，把$session_operator转化成从session中获取的对象，这样的话，后台直接拼装转化后的sql，ok了。这样的话，你想得到哪些数据就可以得到，方便扩展和一些人事方面的特殊需求。等你把权限添加好后，管理员分配时，他会看到这样的结构，订单管理（功能模块权）下有订单历史记录（数据列表权），下面集团数据，公司数据，部门数据，个人数据这些范围权。他选什么就只能看到什么。假如某个人还有个特殊权利，想看到办事处的和已经完成的订单，很简单，你给他添加一个 办事处和已完成这个范围权限，然后把范围设置成@commitUser.deptId like $session_operator.loginUser.deptPath。然后管理员给他分配这个权限就ok了。
我是用java做的 ssh框架，但是对于其他语言的话，其实都差不多，原理是一样的。
我只看了一下你的帖子，感觉应该和我说的类似吧，咱可以讨论讨论。

你的方案写的挺详细的，非常感激，你也会了不少心思吧，呵呵！再次感谢！仔细阅读了你的方案，在你的方案中特有的数据权限设置可能会有点麻烦；数据权限包括能否查看某个部门的数据，能否修改某个部门的数据，能否添加某个部门的数据，能否删除某个部门的数据。你所提出的方案应该可以实现，但这样做是否每个角色都要设置一下每个功能的数据权限（如果是，那系统管理员会非常抵制这种方案，系统给他增加了工作量），另外在这里需要补充一点：不同组织机构单元下的相同的角色他们的数据权限可能大相径庭！

11 楼 hustlxjaw 2010-12-26  

CshBBrain 写道

hustlxjaw 写道

你这样理论上应该是可以实现的，但是通用性不强，稍微发生一点变化很难应对。
如果是我设计数据权限，肯定要求能够灵活管理数据权限组（数据权限的分类依据），然后将数据权限组与功能、角色关联起来。如果数据权限组之间可能也有逻辑关系，这个就需要去定制了；如果数据权限组之间没有逻辑关系，就比较简单了。
另外，SpringSecurity在数据权限控制方面有一个“后拦截”的处理方式，在某种条件下也是可以借鉴的。
上面是我对数据权限的理解，但是暂时还没有时间来整理相关文档，最近在弄报表。。

这位兄台，你所提出得“数据权限组” 以及它和功能，角色之间的关系是否可以说得再详细点以达到通用的目的，还有管理员在设置的时候务必要操作简单，工作量要少，且便于理解。

数据权限组只是将需要划分数据权限的数据的一个分类标准，比如现在有一个数据权限组叫做机构，机构这个数据权限组的内容包括财务部、人力资源部、开发部等。数据权限组只是用来描述数据的划分的，真正的数据权限组下的项才控制数据权限，比如数据都跟财务部、人力资源部产生关系。
通过角色与功能点、数据权限组的管理，可以实现同样的角色，不同功能点具有不同数据权限。

10 楼 AngelAndAngel 2010-12-26  

   你这个问题我曾经也遇到过，我觉得像这种数据权限不能迷信现在的一些所谓的权限框架，只能浪费时间。首先你要的是数据权限控制，而数据权限呢是需要通过菜单权限来体现的，这里面有重合也有不同点。你如你刚才举得例子，如
集团--公司--办事处--部门--个人,有可能这四个域里面的人都有 订单提交历史记录这个菜单权限，那么点击进去呢，会出现各自的数据，比如，集团的域里面需要看到所有集团数据，公司是看到公司所有的数据，办事处，部门，个人以此类推。我们针对这种情况是这样设计的，首先，公司组织部门要设计成树状结构，每个组织（如集团，公司等），在数据库都有自己的部门路径（比如id组成的1,2,3），当然，还得有权限表，用户表，角色表，用户权限表，角色权限表（一般每个人都对应一个角色，而用户权限表是用来给那些特殊人用的，可以在角色权限的基础上多加一些额外的权限）。其次，权限的类别，可以分为，功能模块权限，比如订单管理，用户管理这些大菜单；数据列表权，如上述的订单提交历史；数据操作权（如添加，修改需要的权限）；数据范围权限，控制数据列表的范围的，一般是别的数据列表的子权限，很重要。。下面分类介绍：
  1，功能模块权：很简单，就是属于菜单的权限。就是每棵树的最上级，点击出来也最多是折叠收缩之内的。
  2，数据列表权：重点。比如订单历史列表这样的，点击可得到相应的数据列表的，那怎么得到自己该得到的数据呢，在这个权限下面一般都会有类别为数据范围的子权限，如集团数据，公司数据，办事处数据，部门数据，个人数据这些，添加这类子权限的时候，会让你输入范围，举个例子，假如这个人他只能看到本部门数据，那么可以这样填写范围
@commitUser.deptId=$session_operator.loginUser.deptId。在后台呢，专门设计一个通用的解析这类语句的工具，如把@号可以自动转换成你的数据表的别名(当然，你的订单表中肯定要有commiUser字段啊)，把$session_operator转化成从session中获取的对象，这样的话，后台直接拼装转化后的sql，ok了。这样的话，你想得到哪些数据就可以得到，方便扩展和一些人事方面的特殊需求。等你把权限添加好后，管理员分配时，他会看到这样的结构，订单管理（功能模块权）下有订单历史记录（数据列表权），下面集团数据，公司数据，部门数据，个人数据这些范围权。他选什么就只能看到什么。假如某个人还有个特殊权利，想看到办事处的和已经完成的订单，很简单，你给他添加一个 办事处和已完成这个范围权限，然后把范围设置成@commitUser.deptId like $session_operator.loginUser.deptPath。然后管理员给他分配这个权限就ok了。
我是用java做的 ssh框架，但是对于其他语言的话，其实都差不多，原理是一样的。
我只看了一下你的帖子，感觉应该和我说的类似吧，咱可以讨论讨论。

9 楼 CshBBrain 2010-12-26  

hustlxjaw 写道

你这样理论上应该是可以实现的，但是通用性不强，稍微发生一点变化很难应对。
如果是我设计数据权限，肯定要求能够灵活管理数据权限组（数据权限的分类依据），然后将数据权限组与功能、角色关联起来。如果数据权限组之间可能也有逻辑关系，这个就需要去定制了；如果数据权限组之间没有逻辑关系，就比较简单了。
另外，SpringSecurity在数据权限控制方面有一个“后拦截”的处理方式，在某种条件下也是可以借鉴的。
上面是我对数据权限的理解，但是暂时还没有时间来整理相关文档，最近在弄报表。。

这位兄台，你所提出得“数据权限组” 以及它和功能，角色之间的关系是否可以说得再详细点以达到通用的目的，还有管理员在设置的时候务必要操作简单，工作量要少，且便于理解。

8 楼 nethaoke 2010-12-25  

建议把菜单功能的数据权限控制策略放到表级别  还有针对A集团能访问B集团的数据  可以设置一个表 维护集团之间共享数据的表 再针对表的访问级别 访问相应的数据  把数据的访问级别放到表级别 把功能的访问权限如菜单的访问放到角色级别

7 楼 tianlinzx 2010-12-25  

有没有考虑 Shiro的Permission控制？？？这个库轻巧，功能也足。建议楼主参考一下。

6 楼 hustlxjaw 2010-12-25  

你这样理论上应该是可以实现的，但是通用性不强，稍微发生一点变化很难应对。
如果是我设计数据权限，肯定要求能够灵活管理数据权限组（数据权限的分类依据），然后将数据权限组与功能、角色关联起来。如果数据权限组之间可能也有逻辑关系，这个就需要去定制了；如果数据权限组之间没有逻辑关系，就比较简单了。
另外，SpringSecurity在数据权限控制方面有一个“后拦截”的处理方式，在某种条件下也是可以借鉴的。
上面是我对数据权限的理解，但是暂时还没有时间来整理相关文档，最近在弄报表。。

5 楼 CshBBrain 2010-12-25  

主要是设计方案上，具体的实现可以不考虑；acgi几年前改造过，已经放弃这个很久了，在菜单功能权限控制方面还不如我自己实现的好，尤其是效率上面；数据权限控制和功能菜单的控制是又差别的，感觉扩展acgi达不到我的目标。
另外权限控制方面的东西我也做了些，具体的实现技术和思想不是什么问题，只要有好的解决方案。

4 楼 抛出异常的爱 2010-12-25  

没有多平台通讯的问题的话.
很多系统都有这种功能
都是层级可配置的

3 楼 CshBBrain 2010-12-25  

这么冷清呀，我先说说自己的考虑吧，希望能起到抛砖引玉的作用：
1.系统肯定提供菜单功能注册管理的功能，且细化到功能按钮级别（增删改查），每个菜单功能都设计一个 【数据权限控制策略】，分为系统控制级：系统中所有用户都可以维护，集团控制级别：集团内所有用户都可以维护，公司分公司级别：公司分公司中的所有用户都可以维护，部门级别：部门内所有用户都可以维护，用户级别：只有数据的创建人可以维护。
2.数据权限和具体部门下的角色也有很大的关系，所以系统中少不了角色；给每个角色设计一个【数据权限控制策略】，分为系统控制级：可以维护系统中所有数据，集团控制级别：可以维护集团内所有数据，公司分公司级别：可以维护公司分公司内的所有数据，部门级别：可以维护部门内所有数据。
3.另外为了解决无规则的数据权限控制需求，设计一个针对部门下面的角色和人的数据权限授予功能，可以在这里指定角色或人能维护哪些组织机构单元中的数据（本来打算使用这一种方式处理所有权限控制，但考虑到系统管理员授予数据权限的工作量太大，系统管理员非常抵制这种做法）。
4.数据权限的过滤技术需要使用到AOP拦截器,过滤器以及权限数据的缓存，将某次查询的数据过滤条件附件到具体的查询条件上，好了，这里先抛开具体的实现技术和方法。
5.数据权限计算规则：
5.1如果此菜单功能的【数据权限控制策略】为系统级别，好说，不做任何数据过滤。
5.2如果此菜单功能的【数据权限控制策略】为集团级别，则如果当前访问用户的角色的【数据权限控制策略】为系统级别，则不做任何数据过滤；如果当前访问用户的角色的【数据权限控制策略】为集团级别以及更低的级别，则不用户可以访问其所在集团的所有数据 + 授予给此角色或用户的特殊数据权限。
5.2如果此菜单功能的【数据权限控制策略】为公司级别，则如果当前访问用户的角色的【数据权限控制策略】为系统级别，则不做任何数据过滤；如果当前访问用户的角色的【数据权限控制策略】为集团级别，则不用户可以访问其所在集团的所有数据 + 授予给此角色或用户的特殊数据权限。如果当前访问用户的角色的【数据权限控制策略】为公司级别以及更低的级，则当前用户可以访问其所在公司的所有数据 + 授予给此角色或用户的特殊数据权限。
依次类推。。。。。。。。

但客户还是觉得麻烦，有没有更简单的方案呢

2 楼 CshBBrain 2010-12-24  

不需要控制到字段级别。

1 楼 CshBBrain 2010-12-24  

数据权限控制的粒度在针对某条数据是否可以查看，是否可以修改，删除；新增时需要指定数据的归属。