老丁的专栏

开源供应链开发

老丁ID:fly_cloud
14893次访问,排名7712好友0人,关注者1
fly_cloud的文章
原创 6 篇
翻译 0 篇
转载 2 篇
评论 23 篇
逸云的公告
已正式迁移到CCID,网址 -- laoding.blog.ccidnet.com; MSN: ilaoding@hotmail.com
最近评论
freesea1:# aran 发表于2006-09-05 18:22:00 IP: 61.237.235.*
文章确实不错,但是有个问题需要请教,系统功能是否允许用户增删改,如果被删除是否影响程序使用
如:采购入库单的新增按钮怎么和用户的采购入库单的新增权限的挂钩.新增按钮的id和功能编码有关系?

# laoding 发表于2006-09-06 13:1……
bingdian37:对,不够抽象
正在考虑一个对于RBAC的扩展模型,可以解决这样的问题
skyswan:对于树形角色和角色组如何处理呢?比如说父级角色可以访问其所有子级(含子级的子级)的数据?
chufeng:从数据库结构看,该权限系统是完全RBAC(基于角色控制方法)。在角色上定义了该角色可以访问的菜单、功能按钮,同时,也定义该角色可以操作的数据权限,如:部门等。这样,对于销售处经理这样一个角色,按楼主的思想,就会定义成:北京销售处经理,上海销售处经理、、、、等等。这样存在的问题是角色比较多。但是,优点是授权信息少,只要把用户归于某个角色,就可以确定处该用户可以看到的菜单、用户可以操作的按钮、用……
kong:设计不错,我的email:auyeungs@163.com
文章分类
收藏
    相册
    我的收藏
    会员邮件群发
    存档
    软件项目交易
    订阅我的博客
    XML聚合  FeedSky
    订阅到鲜果
    订阅到Google
    订阅到抓虾
    订阅到BlogLines
    订阅到Yahoo
    订阅到GouGou
    订阅到飞鸽
    订阅到Rojo
    订阅到newsgator
    订阅到netvibes

    原创 通用数据权限管理系统设计收藏

    新一篇: SCM项目简介 | 

    通用数据权限管理系统设计(一)
     
    作者:逸云
     
    前言:
     本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。
     
    解释:
     功能权限:能做什么的问题,如增加销售订单;
     数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单;
     
    术语:
     资源:系统中的资源,主要是各种业务对象,如销售单、付款单等;
     操作类型:对资源可能的访问方法,如增加、删除、修改等;
     功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等;
     数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等;
     数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;
     权限:角色可使用的功能,分角色的功能权限和角色的数据权限;
     角色:特定权限的集合;
     用户:参与系统活动的主体,如人,系统等。
     
     
    通用数据权限管理系统设计(二)
     
    方法说明:
     在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。
     
     本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。
    本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。
     
     这段话比较绕口,下面举个例子实际例子。
     
     某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:
        销售总监      -- 能察看所有销售部的销售订单;
        北京销售经理 -- 只能察看北京销售部的所有销售订单;
        上海销售经理 -- 只能察看上海销售部的所有销售订单;  
        广州销售经理 -- 只能察看广州销售部的所有销售订单;  
     
     上述角色的定义如下:
     
         -------------------------------------------------------------------
         角色名称             功能             数据类型     数据对象  
         -------------------------------------------------------------------
         销售总监           察看销售订单                                 
         北京销售经理       察看销售订单         部门         北京  
         上海销售经理       察看销售订单         部门         上海     
         广州销售经理       察看销售订单         部门         广州     
         -------------------------------------------------------------------
     
        上述定义中,销售总监只定义了功能权限,而没有定义数据权限,所以销售总监能够察看所有的销售订单;而其他几位销售经理分别定义了这一功能的数据权限,所以只能察看指定部门的销售订单。
     
         在实际应用中,往往会出现部门分组,组长能够察看本组所有人员处理的销售订单的情况,以及某些情况下,某些人只能察看本人的销售订单的情况,这些特殊情况在上述的说明中无法解决,需要在设计和实现中进行处理。
     
     
        北京销售代表 -- 只能察看北京销售部的本人的所有销售订单;  
         北京销售代表         察看销售订单           部门            北京     
                                                     个人                  
     
     
    通用数据权限管理系统设计(三)--数据库设计
     
    我们先来看看传统的基于角色的权限管理系统,如下图所示,最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。
        图一:基于角色的数据库结构
    为实现数据权限控制,在设计上对基于角色的权限管理进行扩充,如下图所示:
     
    图二:通用数据权限管理系统数据库设计
    对比两张图,我们可以看到,他们之间的主要变化为:
    1、 增加系统资源信息和操作类型信息,系统资源为树形结构、如销售模块、销售订单等;操作类型记录可能的操作,如增加、删除、修改、查看、查询等,系统功能是资源与操作类型的组合,对资源的操作就是系统功能。
    2、 增加数据对象类型和数据对象两张表,数据对象类型记录系统中需要控制的对象类型,如部门、库房、员工、客户、供应商等;数据对象记录各对象类型的对象实例,如北京销售部、上海销售部、张三、李四等等。(独立保存的好处后面会说到)
    3、 增加系统资源与数据对象类型的关联表(多对多),本表为配置表,说明某种资源可能需要的控制点,如销售订单与部门类型的关联可能涉及到分部门分配权限;销售订单与客户的关联可能涉及到按客户分配权限等等。
    4、 增加数据对象与角色权限的关联,这张表是真正最终实现数据权限管理的所在地。
     
    通过这种设计,能够最小化地减少对原有权限系统的更改,并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用,能够灵活满足客户的需要。
     
    下一篇文章将讨论这种结构如何满足第二部分功能需求的问题,如果时间允许,将对程序的设计做进一步阐述。
     
    本设计方法已应用于自行开发的通用供应链管理系统中,欢迎指正。
     开源供应链[进销存]系统说明目录

     

    发表于 @ 2006年08月09日 13:52:00|评论(loading...)|编辑

    新一篇: SCM项目简介 | 

    评论

    #laok 发表于2006-08-10 15:51:00  IP: 159.226.3.*
    关于定义角色的部分,是否可以考虑定义一系列具有动态特性的角色,比如文中的销售经理定义为角色,而不是将广州销售经理、北京销售经理之类的定义为角色,通过进一步抽象,结构上可能会更加清晰一点。
    #老丁 发表于2006-08-10 16:11:00  IP: 219.142.122.*
    to:Loak
    将销售经理定义为角色的情况下,需要将其对部门对象的数据权限定义为仅用于本部门,这样也可以实现不同地区经理有不同权限的问题.

    本文中只所以分开,主要考虑是描述的更清晰一些
    #rill 发表于2006-08-10 17:53:00  IP: 159.226.5.*
    写的挺好,就是还没有完全看懂 呵呵
    #aaaaaaaa 发表于2006-08-11 11:33:00  IP: 210.83.203.*
    路过看看,挺好!
    #胡立新 发表于2006-08-12 20:21:00  IP: 220.180.134.*
    确实不错
    # 发表于2006-08-12 20:30:00  IP: 220.180.134.*
    开源供应链软件在哪里下载?
    #老丁 发表于2006-08-13 14:22:00  IP: 61.48.55.*
    目前还没有找到正式公布,有一个测试网址:http://219.238.239.50/netmarket/
    由于服务器配置问题,目前只能看到英文的(菜单除外)
    #很好,但可以完善 发表于2006-08-16 16:27:00  IP: 124.203.146.*
    分析的很好,但是还需要完善:
    1、权限模型本质要素分为三个:主体+动作+客体
    2、权限的表现类型分为两种:静态权限(常规权限)和动态权限(工作流程)
    #老丁 发表于2006-08-17 18:05:00  IP: 219.142.122.*
    To:很好,但可以完善
    -----------------------------------------------------------------
    1、权限模型本质要素分为三个:主体+动作+客体
    -----------------------------------------------------------------
    权限问题是who do what的问题,
    数据权限是who do what in which scope的问题

    ----------------------------------------------------------------
    2、权限的表现类型分为两种:静态权限(常规权限)和动态权限(工作流程)
    ----------------------------------------------------------------
    想请教一下,这里的动态权限具体指的是什么?是授权?还是业务流程到某一状态后才能具备的功能?比如,销售订单没有没有审批就不能办理出库等等?
    #jerry 发表于2006-08-22 08:13:00  IP: 218.79.234.*
    这篇文章的确很不错,下一篇什么时候发表呢?期待……
    #aran 发表于2006-09-05 18:22:00  IP: 61.237.235.*
    文章确实不错,但是有个问题需要请教,系统功能是否允许用户增删改,如果被删除是否影响程序使用
    如:采购入库单的新增按钮怎么和用户的采购入库单的新增权限的挂钩.新增按钮的id和功能编码有关系?
    #aran 发表于2006-09-06 13:32:00  IP: 61.237.234.*
    谢谢回复.新的请教发到新博客中去了
    #laoding 发表于2006-09-06 13:15:00  IP: 219.142.122.*
    to:aran
    在正常发布后,功能(如新增采购订单)是不能删除的,但可以处理某个角色是否具有某项功能功能.

    用户的权限在权限管理部分设置,在业务操作时,新增操作后在Logic层进行权限的检查,Logic层的相关方法中有类似于功能编码的识别符(本系统中不使用功能编码)。
    #chufeng 发表于2006-09-24 19:16:00  IP: 59.57.193.*
    从数据库结构看,该权限系统是完全RBAC(基于角色控制方法)。在角色上定义了该角色可以访问的菜单、功能按钮,同时,也定义该角色可以操作的数据权限,如:部门等。这样,对于销售处经理这样一个角色,按楼主的思想,就会定义成:北京销售处经理,上海销售处经理、、、、等等。这样存在的问题是角色比较多。但是,优点是授权信息少,只要把用户归于某个角色,就可以确定处该用户可以看到的菜单、用户可以操作的按钮、用户可以访问的数据。

    个人感觉这样的模型,不够抽象。现实生活中,应该是只有一个销售处经理的角色,而,不同的人都属于这个角色,但是分管的地区不一样而已。所以,应该把角色的数据权限,授权到人身上。即:角色、人、数据,唯一确定一条授权。

    但是,不同的系统,可能适合不同的模型。对于像楼主所说的这样的系统,角色非常多,就应该采用第二种方式。而如果系统角色比较少,而且大部分用户操作权限都一致,就可以考虑第一种方式,因为授权会比较少。
    #skyswan 发表于2006-12-25 13:39:23  IP: 219.133.117.*
    对于树形角色和角色组如何处理呢?比如说父级角色可以访问其所有子级(含子级的子级)的数据?
    #bingdian37 发表于2008-01-06 22:53:37  IP: 59.81.133.*
    对,不够抽象
    正在考虑一个对于RBAC的扩展模型,可以解决这样的问题
    #freesea1 发表于2008-03-18 12:14:24  IP: 218.17.69.*
    # aran 发表于2006-09-05 18:22:00 IP: 61.237.235.*
    文章确实不错,但是有个问题需要请教,系统功能是否允许用户增删改,如果被删除是否影响程序使用
    如:采购入库单的新增按钮怎么和用户的采购入库单的新增权限的挂钩.新增按钮的id和功能编码有关系?

    # laoding 发表于2006-09-06 13:15:00 IP: 219.142.122.*
    to:aran
    在正常发布后,功能(如新增采购订单)是不能删除的,但可以处理某个角色是否具有某项功能功能.

    用户的权限在权限管理部分设置,在业务操作时,新增操作后在Logic层进行权限的检查,Logic层的相关方法中有类似于功能编码的识别符(本系统中不使用功能编码)。


    laoding 你好,能否再详细点,我现在就是不太明白页面元素(比如删除采购订单按钮)怎么和权限挂构(不可能按钮都判断一下,有则显示没有就不显示,能否在页面装入的时间就判断所有的按钮而不是每一个呢,但是我就是不知道怎么实现,望解答,谢谢)
    2008-03-26 15:50:18作者回复
    TO:freesea1<br />&gt;系统功能是否允许用户增删改,如果被删除是否影响程序使用<br />系统功能的删除没有问题,唯独就是删掉以后该功能肯定就不能用,因为验证不通过。<br />增加的话,需要在代码里做相应的处理<br /><br /><br />&gt;采购入库单的新增按钮怎么和用户的采购入库单的新增权限的挂钩.新增按钮的id和功能编码有关系? <br />如果要设置到按钮级,并且处理涉及到是否显示的话,需要设计按钮与功能之间的关系。<br />如果不是上面的话,按钮的ID和功能编码无关<br /><br />
    发表评论  


    当前用户设置只有注册用户才能发表评论。如果你没有登录,请点击登录
    Csdn Blog version 3.1a
    Copyright © 逸云