信息系统的权限控制

最新推荐文章于 2023-06-14 08:44:42 发布

pll123

最新推荐文章于 2023-06-14 08:44:42 发布

阅读量649

点赞数

文章标签： user 文档扩展工作电子商务 delete

本文链接：https://blog.csdn.net/pll123/article/details/3412659

版权

http://topic.csdn.net/t/20040712/16/3167567.html

常用信息系统权限解析

在长期的软件行业从业经验中，设计与见识了各种各样的权限体系。

我们先从一个浅显的权限表设计着手。
表结构：
UserID int UserName Varchar(50) ……
Perm1 bool
Perm2 bool
……
您一定看出这个是个幼稚的设计。是的，这个设计十分浅显，而且非常不利于扩展。细化的时候，USER表最终会变的不可维护。不用觉得奇怪，这个设计是笔者在一个电子商务公司现运行的系统中发现的。当时这个系统的开发者与维护者正陷入痛苦的权限变更中。为了解决这个问题，我们从常用的两大类权限设计来分析。

1．针对操作授权。
    目前国内大部分的信息系统，市场上流行的各种论坛，Blog等都是采用这种方式，或者这种方式的变种。我们先从一个简单的例子谈起。一个定单操作的例子：针对订单操作，可能有如下权限：CreateOrder, ViewOrder, UpdateOrder, StatOrder, DeleteOrder, ApproveOrder等。组织结构如下所描述:
      ◇ 总经理--> 下属三个部门: 业务部门一,业务部门二, 财务部门
     ◇ 业务部门一: 业务员甲, 经理甲
      ◇ 业务部门二: 业务员乙, 经理乙
     ◇ 财务部门: 经理丁, 财务专员
    如此针对定单操作就有个简单的二维模型 :

原子权限/用户经理甲 ...
View           true
Create          false
Update               true
Delete         true
Approve      true
Stat              true

其他人员的权限设置类似. ,到这里为止, 权限模型似乎建立的很成功,因为其简单, 在一些小型应用系统中也确实不少是采用这种方式来工作.下面来谈谈实现的问题. 首先建立二个实体类: 1;User, 2,Permission ;3.UserPerm. User表示用户信息; Permission表示操作权限. UserPerm记录用户与操作权限的关联.如此可针对每个用户动态的绑定与撤消权限.

目前为止以上设计工作的似乎很好, 但是需求总是不断变化的，现在需要软件使用人员针对单个用户来授权,业务复杂了，使用人员多了，从操作角度而言,十分不便.组的概念在这里就有了使用之地. 在这里添加一个表 4. Group 下面看一个对以上权限的一个扩展实现就前面的简单的组织架构而言, 设置一个业务经理Group, 把所有的业务经理归结为一个BussManager组, 然后在针对这个组来授权. 于是, 不管有多少个业务部门,经理们都能得到统一的权限管理. 比如, 当总经理需要业务经理的所有权限时, 可以把总经理添加到 BussManager组. 如此则业务经理所拥有的权限,总经理都拥有. 业务模型如此实现,OK, 基本上的权限控制都可以控制了.

       这里有几个细节, 1. 在授权时候, 要区分用户类型, 是USER, 还是Group
     扩展注意: 如果我部门经理只让看自己部门的定单, 那么该如何实现呢: 这里提出个可行的方案: 1. 对每个原子权限, 设置其级别, 区分个人:部门:分公司; 集团. 具体的级别取决于具体的商业环境.
      到目前为止, 基本上的信息系统的权限就可以应付了。下篇将解析一个比较复杂针对资源授权的权限体系结构.

      二．知识管理系统的权限管理。
       我们知道，针对知识，基本上都是以资源的方式进行管理，可能这个说法比较抽象，拿Windows文件系统做个比方就知道了。资源基本上也是以目录，文档的树型结构进行管理的。本文中，对每个资源统称为对象。对象包括各种资源，文章，分类（目录）等。现在需要做到针对具体目录，具体资源授权。同时做到针对具体用户，组授权。为达到以上目的。我们建立个简单的模型组织结构如下所描述:
      ◇ 总经理--> 下属三个部门: 研发部门一, 研发部门二, 财务部门
     ◇ 3G部门一: 研发员甲, 经理甲
      ◇ CDMA部门二: 研发员员乙, 经理乙
      ◇ 财务部门: 经理丁, 财务专员
资源模型如下：
       ◇ 3G资料目录：文章一，文章二
       ◇ CDMA资料目录：文章三，文章四
       ◇ 财务资料目录：公司财务报告
     有三个目录，数个文档。需要针对具体用户，组。针对具体资源来进行授权。为达到这个目的，我们如此建立权限模型：User, Group , 相同权限的用户可统一为一个组来管理。(可参考目录管理的概念) .

权限:PermDocAdd,PermDocUpdate,PermDocRead,PermDocView,PermDocDelete, PermDirAdd, PermDirRead,PermDirView .针对不同类型的资源，区分不同的Class Type. 来设置不同的原子权限。如果不做进一步的设计, 采取这样的做法，针对每个具体的资源, 动态绑定到原子权限，你会发现工作量太大，而且过细。不是个可行的做法。

      这里就需要引入一个角色的概念。 Role. 设置一个具体的Role(角色):
      ◇ DocEditer: 绑定如下原子权限 PermDocUpdate，PermDocRead, PermDocDelete.          如此一来，只需要对具体的文档进行授权就行了。
      一个角色实例如下：组： 3GGroup，包括用户3G部门下的研发员甲。角色：DocEditer . 资源： 3G资料目录下的文章一
      针对资源文章一，绑定用户（组）3Group 到角色DocEditer. 授权之后，研发员甲就可以浏览，修改，删除文章一了。针对其他资源（比如目录）的权限设置基本同上。上面的权限体系结构比较复杂，如果没有具体的应用背景可能难以理解.主要是针对大型企业, 有着强烈的保密需求而言.