惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

T
Tailwind CSS Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
雷峰网
雷峰网
量子位
有赞技术团队
有赞技术团队
阮一峰的网络日志
阮一峰的网络日志
The Cloudflare Blog
博客园 - Franky
罗磊的独立博客
宝玉的分享
宝玉的分享
博客园_首页
腾讯CDC
The GitHub Blog
The GitHub Blog
D
DataBreaches.Net
IT之家
IT之家
D
Docker
Microsoft Security Blog
Microsoft Security Blog
博客园 - 司徒正美
V
V2EX
月光博客
月光博客
N
Netflix TechBlog - Medium
爱范儿
爱范儿
I
InfoQ
P
Proofpoint News Feed

博客园 - rodney

Tushare环境搭建 用Python做量化交易Tushare平台获取数据 未能加载文件或程序集“System.Web.Razor”或它的某一个依赖项。文件或目录损坏且无法读取。 iis7应用程序池自动关闭问题解决 贝乐福可以做电商 解决在Sql Server查询分析器中读取Excel表出现的一些问题 收回误删并清除了回收站的文档 .net framework4.0 下载地址 SQL2008 R2 VS2010开发环境安装 博文阅读密码验证 - 博客园 ExtJs学习 当事人在土地征收补偿纠纷中需要收集的证据类型 当事人在土地征收补偿纠纷中需要收集的证据 log4net详细配置 转 RBAC原理介绍及kasai使用分析 基于RBAC的权限设计-3 权限管理设计-1 谈谈对于企业级系统架构的理解 转来的 SQL 字符串分割
权限管理设计-2
rodney · 2011-06-19 · via 博客园 - rodney

作者:逸云

前言:

 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。

解释:

 功能权限:能做什么的问题,如增加销售订单;

 数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单;

术语:

 资源:系统中的资源,主要是各种业务对象,如销售单、付款单等;

 操作类型:对资源可能的访问方法,如增加、删除、修改等;

 功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等;

 数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等;

 数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;

 权限:角色可使用的功能,分角色的功能权限和角色的数据权限;

 角色:特定权限的集合;

 用户:参与系统活动的主体,如人,系统等。

通用数据权限管理系统设计(二)

方法说明:

 在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。

 本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。

本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。

 这段话比较绕口,下面举个例子实际例子。

 某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:

    销售总监      -- 能察看所有销售部的销售订单;

    北京销售经理 -- 只能察看北京销售部的所有销售订单;

    上海销售经理 -- 只能察看上海销售部的所有销售订单;  

    广州销售经理 -- 只能察看广州销售部的所有销售订单;  

 上述角色的定义如下:

     -------------------------------------------------------------------

     角色名称             功能             数据类型     数据对象  

     -------------------------------------------------------------------

     销售总监           察看销售订单                                 

     北京销售经理       察看销售订单         部门         北京  

     上海销售经理       察看销售订单         部门         上海     

     广州销售经理       察看销售订单         部门         广州     

     -------------------------------------------------------------------

    上述定义中,销售总监只定义了功能权限,而没有定义数据权限,所以销售总监能够察看所有的销售订单;而其他几位销售经理分别定义了这一功能的数据权限,所以只能察看指定部门的销售订单。

     在实际应用中,往往会出现部门分组,组长能够察看本组所有人员处理的销售订单的情况,以及某些情况下,某些人只能察看本人的销售订单的情况,这些特殊情况在上述的说明中无法解决,需要在设计和实现中进行处理。

    北京销售代表 -- 只能察看北京销售部的本人的所有销售订单;  

     北京销售代表         察看销售订单           部门            北京     

                                                 个人                  

通用数据权限管理系统设计(三)--数据库设计

我们先来看看传统的基于角色的权限管理系统,如下图所示,最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。

    图一:基于角色的数据库结构

为实现数据权限控制,在设计上对基于角色的权限管理进行扩充,如下图所示:

图二:通用数据权限管理系统数据库设计

对比两张图,我们可以看到,他们之间的主要变化为:

1、 增加系统资源信息和操作类型信息,系统资源为树形结构、如销售模块、销售订单等;操作类型记录可能的操作,如增加、删除、修改、查看、查询等,系统功能是资源与操作类型的组合,对资源的操作就是系统功能。

2、 增加数据对象类型和数据对象两张表,数据对象类型记录系统中需要控制的对象类型,如部门、库房、员工、客户、供应商等;数据对象记录各对象类型的对象实例,如北京销售部、上海销售部、张三、李四等等。(独立保存的好处后面会说到)

3、 增加系统资源与数据对象类型的关联表(多对多),本表为配置表,说明某种资源可能需要的控制点,如销售订单与部门类型的关联可能涉及到分部门分配权限;销售订单与客户的关联可能涉及到按客户分配权限等等。

4、 增加数据对象与角色权限的关联,这张表是真正最终实现数据权限管理的所在地。

通过这种设计,能够最小化地减少对原有权限系统的更改,并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用,能够灵活满足客户的需要。

下一篇文章将讨论这种结构如何满足第二部分功能需求的问题,如果时间允许,将对程序的设计做进一步阐述。

本设计方法已应用于自行开发的通用供应链管理系统中,欢迎指正。

 开源供应链[进销存]系统说明目录

作者:逸云

前言:

 本文提供一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是RBAC(基于角色的访问控制方法)的进一步扩展和延伸,即在功能权限的基础上增加数据权限的管理,实现数据权限和功能权限的集中处理。

解释:

 功能权限:能做什么的问题,如增加销售订单;

 数据权限:能在哪里干什么的问题,如察看北京分公司海淀销售部张三的销售订单;

术语:

 资源:系统中的资源,主要是各种业务对象,如销售单、付款单等;

 操作类型:对资源可能的访问方法,如增加、删除、修改等;

 功能:对资源的操作,是资源与操作类型的二元组,如增加销售单、修改销售单等;

 数据类型:业务系统中常用的数据权限类型,如公司、部门、项目、个人等;

 数据对象:具体的业务对象,如甲公司、乙部门等等,包括所有涉及到数据权限的对象值;

 权限:角色可使用的功能,分角色的功能权限和角色的数据权限;

 角色:特定权限的集合;

 用户:参与系统活动的主体,如人,系统等。

通用数据权限管理系统设计(二)

方法说明:

 在实际应用中,数据权限的控制点一般相对固定,如针对公司、部门、个人、客户、供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象。

 本方法中,数据权限的依赖于功能权限,是对功能权限的进一步描述,说明角色在指定的功能点上的数据控制权限。

本方法中采用“没有明确规定即视为有效”的原则,如果没有定义功能的数据权限,则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限,则该用户只具有该类型下指定数据的数据权限。

 这段话比较绕口,下面举个例子实际例子。

 某公司有北京销售部、上海销售部和广州销售部三个销售部,现在需要定义几种角色:

    销售总监      -- 能察看所有销售部的销售订单;

    北京销售经理 -- 只能察看北京销售部的所有销售订单;

    上海销售经理 -- 只能察看上海销售部的所有销售订单;  

    广州销售经理 -- 只能察看广州销售部的所有销售订单;  

 上述角色的定义如下:

     -------------------------------------------------------------------

     角色名称             功能             数据类型     数据对象  

     -------------------------------------------------------------------

     销售总监           察看销售订单                                 

     北京销售经理       察看销售订单         部门         北京  

     上海销售经理       察看销售订单         部门         上海     

     广州销售经理       察看销售订单         部门         广州     

     -------------------------------------------------------------------

    上述定义中,销售总监只定义了功能权限,而没有定义数据权限,所以销售总监能够察看所有的销售订单;而其他几位销售经理分别定义了这一功能的数据权限,所以只能察看指定部门的销售订单。

     在实际应用中,往往会出现部门分组,组长能够察看本组所有人员处理的销售订单的情况,以及某些情况下,某些人只能察看本人的销售订单的情况,这些特殊情况在上述的说明中无法解决,需要在设计和实现中进行处理。

    北京销售代表 -- 只能察看北京销售部的本人的所有销售订单;  

     北京销售代表         察看销售订单           部门            北京     

                                                 个人                  

通用数据权限管理系统设计(三)--数据库设计

我们先来看看传统的基于角色的权限管理系统,如下图所示,最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。

    图一:基于角色的数据库结构

为实现数据权限控制,在设计上对基于角色的权限管理进行扩充,如下图所示:

图二:通用数据权限管理系统数据库设计

对比两张图,我们可以看到,他们之间的主要变化为:

1、 增加系统资源信息和操作类型信息,系统资源为树形结构、如销售模块、销售订单等;操作类型记录可能的操作,如增加、删除、修改、查看、查询等,系统功能是资源与操作类型的组合,对资源的操作就是系统功能。

2、 增加数据对象类型和数据对象两张表,数据对象类型记录系统中需要控制的对象类型,如部门、库房、员工、客户、供应商等;数据对象记录各对象类型的对象实例,如北京销售部、上海销售部、张三、李四等等。(独立保存的好处后面会说到)

3、 增加系统资源与数据对象类型的关联表(多对多),本表为配置表,说明某种资源可能需要的控制点,如销售订单与部门类型的关联可能涉及到分部门分配权限;销售订单与客户的关联可能涉及到按客户分配权限等等。

4、 增加数据对象与角色权限的关联,这张表是真正最终实现数据权限管理的所在地。

通过这种设计,能够最小化地减少对原有权限系统的更改,并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用,能够灵活满足客户的需要。

下一篇文章将讨论这种结构如何满足第二部分功能需求的问题,如果时间允许,将对程序的设计做进一步阐述。

本设计方法已应用于自行开发的通用供应链管理系统中,欢迎指正。

posted on 2011-06-19 09:18  rodney  阅读(771)  评论()    收藏  举报