基于RBAC通用权限模型分析.docx

统一授权解决方案 模版编号：icinfo_rd_tem_03浙江大学统一授权解决方案版 本：v0.1文档编号zdtysf2_rd_tem_03保密等级 作者吉日嘎拉编写日期2008-10-30审核人审核日期批准人批准日期修订记录日期版本修订说明修订人2008-10-30v0.1初稿吉日嘎拉目录1.权限的可行性分析61.1理论基础61.2核心概念61.3权限分类71.4组织机构的数据集权限体系81.4.1常用管理关系分析101.4.2管理模型的最终目的121.4.3技术可行性121.4.4开发可行性131.4.5实施可行性131.4.6维护可行性132.权限常见的问题分析132.1原理层面的问题132.2q/a列表143.实现通用权限模型183.1权限183.1.1操作权限定义183.1.2操作权限维护193.1.3操作权限203.1.4操作权限注意事项203.1.5列表型资源权限203.1.6树型资源权限203.1.7权限域213.1.8拒绝权限213.1.9权限映射223.2用户243.2.1用户权限逻辑图243.2.2用户角色逻辑图253.3用户默认角色253.3.1数据导入问题253.3.2实际需求263.4角色263.4.1用户-角色-权限263.4.2注意事项及原则263.4.3角色分类263.4.4角色权限关系273.4.5角色用户关系283.4.6操作权限实现参考293.5组织机构313.5.1组织机构管理323.5.2组织机构与用户管理323.5.3组织机构与角色关系323.6分级授权、分级管理333.6.1分级授权333.6.2分级管理实现343.6.3操作权限分级授权343.6.4权限域分级授权353.7权限域353.7.1权限域细化问题363.7.2权限域叠加问题373.8模块菜单383.8.1模块管理383.8.2模块权限挂接383.8.3模块配置383.9标准日志393.9.1访问情况403.9.2按用户查询403.9.3按模块查询413.9.4按日期查询413.10等同权限413.11帐号扮演413.12委托代理423.13大规模多业务授权实施策略424.权限规范实际应用434.1数据结构直接引用434.2规范类库包、通用函数引用434.3后台管理工具引用444.4承包商开发规范化444.5统一集中授权445.实际开发用例465.1权限场景描述465.2运行模式配置475.3页面实现层权限变量定义475.4页面实现层获取权限变量485.5权限变量与页面控件逻辑结合485.6浙江大学大型仪器信息服务系统496.实际开发经验教训总结526.1表结构整体总结526.2权限表结构总结526.3组件化总结526.4开发架构转变总结536.5设计与实施差别总结536.6开发过程经验总结536.7规范化推进过程总结547.附件通用权限表结构设计参考557.1权限表列表557.2权限配置表（base_permission）557.3组织机构表（base_organize）567.4用户表（base_user）567.5用户组织机构关系表（base_userorganize）577.6角色表（base_role）577.7用户角色关系表（base_userrole）587.8资源权限表（base_resourcepermission）587.9资源权限域表（base_resourcepermissionscope）591. 权限的可行性分析我们开发各种软件项目过程中，经常需要开发配套的后台管理程序。通过后台权限设置，控制前台业务逻辑。当你开发的软件项目越来越多时，你需要开发的后台管理也会越来越多，这时有统一的权限后台来管理业务系统，实现系统有统一的帐号，由统一的授权体系来管理多个后台。1.1理论基础参考标准：nist （the national institute of standards and technology，美国国家标准与技术研究院）基本模型rbac0（core rbac）1.2核心概念access control objects (acos) 权限控制对象（aco对象）是我们想要控制的事物（如网页，数据库，房间等）access request objects (aros) 权限需求对象（aro对象）是要求权限的事物（如用户，远程计算机等），aro tree aro树则定义了aro对象及组的级别，组可以包含其他组和aro对象。aro树缺省的catch-all（全部阻止了）策略总是拒绝所有权限的。自顶向下的权限系统，权限有权限分组，请求对象有请求对象分组，users是请求对象的分组。在aro树上按照你的想法自顶向下明确地为每一个aco对象分配所需的权限给组和aro对象。access extention object (axo) 权限扩展对象可以通过配置axo对象为第三方添加权限。用最通俗的话来讲，权限要实现2个核心功能，一个是：谁（什么）有哪种权限？这个是属于操作权限范畴，另一个是：谁（什么）对什么（谁）有哪种权限？这个属于数据集权限范畴。从严格意义上来讲，操作权限属于数据集权限的一个特例，是在全数据集范围内的权限限制。图表表示：什么资源（例如 用户、角色、计算机）有什么权限（操作权限）。图表表示：什么资源（例如 用户、角色、计算机）对什么资源（例如 用户、角色、计算机）有什么权限（操作权限），以上是实现权限域的功能。1.3权限分类当一个系统权限问题考虑的比较多因素时，头脑就会有点乱，所以是需要简化权限系统配置，理清思路。业务系统按权限的定位策略，可以分为2大类，开放性业务系统、封闭性业务系统。开放性业务系统：如新闻类网站，用户不受限制访问网站上的所有信息。封闭性业务系统：例如要求严格的业务管理系统，操作人员的每步操作都需要进行权限认证，不能访问未经授权的资源，也不能有越权的处理能力。权限从可配置的角度，可分为：可配置权限、固化到业务流程中的个性化权限。权限大体上可以分为2大类，操作权限（对于用户具有的关于功能模块入口和界面上的功能。操作方面的权限,称之为功能性权限）、数据集权限。操作权限：用户拥有某些具体操作，例如帐户审核权限、校园卡充值权限。数据集权限：用户对特定数据集合上，拥有相应的操作权限。以下以2个实例来表示出操作权限及数据集权限。1.4组织机构的数据集权限体系目前传统的权限分配是以基于组织机构体系的业务分管体系为主。业务系统以某些特定的工作分工领域、例如业务、财务、人事等划分上级管理下级组织的逐级管理体系。权限体系是it与管理相结合的一个问题，所以不光是it的实现方式，重要的是，管理的一些思想已经在未来软件方面的不断变化的需求的方式。以组织机构为管理体系的实例超级管理员管理范围c管理员管理范围a管理员管理范围b管理员管理范围用户、角色及组织机构的关系体系示意图：组织机构为树形结构，方便递归计算权限范围，不用将每个权限范围都要标示出来，只标示根节点，子节点自动计算为有权限的范围内。角色依附于组织机构，这样方便分级管理时实现角色管理的分级授权管理。角色也是组织结构的末端叶子节点。用户依附于组织结构，是组织机构的末端叶子节点。用户用户组、岗位、角色子组织机构基于组织机构的业务数据图实例：实例图各字段说明：id：数据表主键。companyid：公司主键。departmentid：部门主键。userid：用户主键。createuserid：由谁创建数据。createdate：什么时候创建的数据。modifyuserid：由谁最后修改数据。modifydate：最后修改时间。业务数据中，应该有该数据属于哪个组织机构、者哪个用户或者属于那个角色的标示，以实现业务数据过滤的通用性算法，由可以产生一组通用的简化的数据集权限体系，来实现通用的数据权限功能。通过组织机构的管理体系，可以自动推算出某个用户可以管理哪些数据范围。例如，某个用户可以管理哪些可以管理哪些组织（ida, idb,idc），同样也可以推算出被管理用户(ida, idb,idc)等等。由于用户经常会有岗位变动，部门的变动，所以在设计业务数据时，要考虑到以上2个因素，否则权限体系将无法满足实际需要。1.4.1常用管理关系分析用户、角色、组织机构 之间的管理与被管理关系分析为如下 9种情况。1用户 用户 user to user在管理上体现为哪个用户可以管理哪些用户。不建议采用递归的推理。适合小型业务系统的灵活权限分配，适应性最强，最直观的权限管理模式。中大型业务系统中不建议采用此管理模式。2用户 角色 user to role在管理上体现为哪个用户可以管理哪些角色。只建议角色推理到最终被管理的用户为止。3用户 组织机构 user to organize在管理上体现为哪个用户可以管理哪些组织机构。建议组织机构采用树型结构的递归的推理到最终节点。4角色 用户 role to use默认表现为用户默认属于某个角色或者多个角色。在管理上体现为 哪个角色可以管理哪些用户。5角色 角色 role to role在管理上体现为哪个角色可以管理哪些角色。不建议采用递归的推理，采用递归推理，会导致系统的不直观及实施上的混乱，这是大型业务系统中推荐的管理模式，在实施及业务分析上，会存在一定的难度，需要对业务体系进行规范化级分工工作的详细准确整理。6角色 组织机构 role to organize在管理上体现为哪个角色可以管理哪些组织机构。建议组织机构采用树型结构的递归的推理到最终节点。7组织机构 用户 organize to use默认表现为用户默认属于某个组织机构节点、或者用户属于多个组织机构节点上。8组织机构 角色 organize to role默认表现为角色默认属于某个组织机构节点。9组织机构 组织机构 organize to organize默认表现为组织机构的树型结构上，某个组织机构节点属于另一个组织机构节点的子节点，除根节点外。通常业务数据是属于某个用户、角色、组织机构的，业务数据被间接的管理关系管理，假设不对业务数据进行直接的管理关系设置。业务数据的直接权限设置属于，业务权限管理范畴，而不属于系统权限管理范畴。1.4.2管理模型的最终目的通过向管理模型处理体系输入一个用户，可以获得用户所管理的，用户集合、角色集合或组织机构集合，为按某个权限域实现数据集权限的数据过滤提供依据。以组织机构为核心的权限模型的复用率比较高通用性强，稳定性也相对比较高，易于理解，可维护性也比较强。1.4.3技术可行性需要有一定的扩展性，能满足未来的需要。能满足大容量数据的运算，并且逻辑运算不能过于复杂，响应速度要快，以简单的逻辑来解决复杂的实际权限问题。能支持多种数据库，能支持多种技术架构。可以提供多种开发语言的api，可以提供多种数据库的权限sql语句。1.4.4开发可行性对开发人员，首先是不增加复杂度不增加额外工作量，并且学习成本要低易于理解是很关键的。对于测试人员，测试与开发分离，互不影响。对于部署人员，开发与实际部署分离，互不影响。1.4.5实施可行性有专门的实施推进部门、有专项目带动，在权限系统的实施上，应该是有利的保障。1.4.6维护可行性权限的分配不能过于繁杂琐碎，能集中处理授权工作，也能将工作分配给分级管理员，将工作任务合理划分分摊。减少系统维护员的工作压力。可以用统一简便的管理思想、管理工具来维护多个系统，同时可以在数据库层面上能进行维护设置工作处理应急事件的发生及错误的诊断。2.权限常见的问题分析2.1原理层面的问题权限入口问题：权限系统在理想化状态下，不用通过开发人员编辑后台数据库的维护设置来实现权限配置，而是由实施人员进行页面配置就可，这时会遇到一个先有鸡还是先有鸡蛋的类似问题，权限问题的入口问题为，由于当前的操作人员是administrator 用户或者是administrators 组的用户，那当前用户可以有任何操作权限，可以不受限制的进行后台配置。逻辑模型与物理模型的差异：展现形式及统一实现的差异：多个系统的权限控制：操作权限及数据权限的划分：高效的递归算法、权限性能问题：管理思想的混乱：权限的实施推进能力问题：应用理解能力问题：权限及权限范围的问题：业务权限与系统权限的区别：逐级授权分级管理的问题：2.2q/a列表、在resourcepermissionscope的这个表中，targetcategory有个取字的字段，分别是permission,staff,role,organise, 针对这个范围权限中，permission的取值是多余的吗？、我设置合同的表单，如果，我已经设置好了操作权限（如插入、删除、查看、更新、打印、下载等操作权限），如果要在每个操作权限上设置范围权限，那么有那resoucepermissionscope上写什么数据？还要在什么表上写数据？在页面上配置权限的时候，如何进行配置？、在service层，是直接调用层的，虽然定义了接口层，但是没有在之间采用接口？以后会采用接口将层与下面的层进行分离吗？我感觉是否应该应用的接口层？、因为有idbhelper接口的存在，dbhelper在程序中是否就没有用了？回答：dbhelper类是一个静态的数据库访问方法，就不用每次都open,close了，比较简化的数据库防范方式，目前与idbhelper接口没多大关系。5、在中已经有了每个表的字段定义，为什么在basedao中还要定义表的字段定义回答：basedao的定义可以去掉了，我还没去掉，本来是想，不要每个类都写重复的属性定义，在基类里定义就可以了，后来发现这个做法不好，还是每个类自己定义自己的属性比较好。、在business 目录下，有一个的目录，是否现在就不用了？回答：的目录 里的内容，是其他业务逻辑，以前都写过，改版很多次后，这部分还没有按新的格式修正过来，有空了，就在修正一些。跟权限处理关系不大，属于一些比较常用的逻辑业务部分。、我已经把现在的数据库导入到powerdesign中，对于表中的关系，基本能够理解个差不多，对于 操作的权限是比较好理解的，对于范围的关系，尤其还要与页面进行相关，比较难理解，帮我解释看看如何更好的理解这个内容；（我是从2005导入到，然后在中进行reverse就出现了数据库的图）回答：操作权限是比较好理解，例如，a有添加、编辑的权限，但是没有删除的权限。在一个集团公司的应用上，范围权限才能派上大用处，例如 一个集团里有2个公司，分别为ca,cb公司，其中有一个公司的职员a,另一个公司的职员b, 程序要求为，a只能看ca公司的数据，也只能在ca公司的数据上进行添加、编辑权限。b只能看cb公司的数据，也只能在cb公司的数据上进行添加、编辑权限。虽然ab也都有添加、编辑权限，但是他们的范围是不一样的，在一部分特定的数据集合上，有这样的权限。、你发过来的example的个例子都能通，但是如果启动项目设置为winform的时候，执行时候，出现如下错误system.data.sqlclient.sqlexception: 不能将值 null 插入列 processname，表 finance.dbo.base_log；列不允许有空值。insert 失败。 语句已终止。 在 esse.common.service.loginservice.getloginlist(baseuserinfo userinfo) 位置 d:esse.common v1.4esse.common.servicecommonloginservice.cs:行号 100 在 esse.common.uilayer.winform.login.frmlogin.formonload() 位置 d:esse.common v1.4esse.common.uilayer.winformsesse.common.uilayer.winform.loginfrmlogin.cs:行号 123 在 esse.common.uilayer.winform.login.frmlogin.frmlogin_load(object sender, eventargs e) 位置 d:esse.common v1.4esse.common.uilayer.winformsesse.common.uilayer.winform.loginfrmlogin.cs:行号 164 另外，在老的.4的程序中，范围权限定义的时候，会出错回答：这是由于日志记录程序的问题导致的错误，可以将表base_log的processname设置为允许null就可以了，这个程序的主要目的是为了运行权限逻辑等，没怎么考虑日志问题问题，这部分也需要我再仔细完善完善。、数据库表中的字段与类型及中的字段好像不完全一致？、在应用层或层，都有一个数据库open的操作，这样考虑的原因是希望在一个数据连接 中执行多个操作吗？否则就可以完全屏蔽这个数据库连接，把他放入到每一个函数之中。回答：这个需要时考虑了，一个动作，一个服务，应该在一个数据库事务中，一动作是一个事务，其中可能会调用函数a.fa b.fb c.fc 函数，若每个函数都有自己的数据库打开关闭，那就不能形成一个完整的数据库事务了，因为一个事务，应该在一个open close的生命周期里，不能跨越好几个数据库连接的。要么这几个动作都成功，要么这几个动作都可以撤销，而且，一个的方法里，可能组合不同的函数，都应该包括在一个数据库事务里。、在程序中的层，好像没有实现事务操作，是否可能实现这个事务操作？回答：完全可以的，只是没写上去而已。例子程序如下 idbhelper dbhelper = dbhelperfactory.gethelper(); try dbhelper.open(); / 事务开始 dbhelper.begintransaction(); baselogdao.instance.add(dbhelper, methodbase.getcurrentmethod(), userinfo); baseuserdao myuserdao = new baseuserdao(dbhelper, userinfo); ; returnvalue = myuserdao.changepassword(oldpassword, newpassword, out statuscode); / 获得状态消息 statusmessage = myuserdao.getstatecodemessage(statuscode); / 事务递交 dbhelper.committransaction(); catch (exception myexception) / 事务回滚 ; dbhelper.rollbacktransaction(); baseexceptiondao.instance.logexception(dbhelper, userinfo, myexception); throw myexception; finally dbhelper.close(); 、在数据库中，目前没有任何约束关系，我感觉这会对于数据的完整性会产生影响，你当时考虑的是从 编写程序方便的角度把他的链接去掉的吗？数据导入导出应该也可以保留关系，只是可能要烦一点。回答： 按道理，数据库表之间的约束关系，主外键，都应该严格限制的，但是由于历史原因，我用过好几个数据库sql2000,sql2005,还有时候，从高版本回退到过低版本，还用过oralce，同一个程序一直在改进，但是不同的数据库导入导出后，主键、索引、关系都丢失了，一丢失，都需要重新建立过，比较麻烦，最开始也不是严格按pdm设计建立表的，所以，这个关系就没能维护好，若精力充沛些是需要好好维护，好好设置，考虑到所有的数据都是通过程序录入界面录入的，所以很少有不正确的数据在里面，随时可以将约束条件等加上去，这个应该是加上去才对的。、多人同时点击按钮的化，程序会打开多个数据库链接吗？如果是打开数据库的多个链接 出来操作，为什么会产生错误？而为什么会这样的操作进行上锁？回答： 多人同时点击按钮时，看你是用什么运行模式，若是 本地模式，那是程序在每个人的电脑上都会运行一个服务程序，所以会存在打开多个数据库连接的问题，这时候，主键产生的方法，可能会有并发问题存在，可能a，也产生了100这个主键，b也产生了100这个主键，插入数据时会发生主键冲突问题，在orcale数据上，获取主键的算法，进行了优化，产生主键时，先对表进行了锁定的操作，所以不会导致并发问题，不会产生重复的主键。basesequencedao中 用了oracle里的 for update nowait 语句，对表进行了锁定操作。、在跟踪程序中，发现instance的值在执行到不同的类时候，是会变化的，这如何理解？另外，程序一开始，就执行一个instance的类，确定了这个服务类在程序一启动的时候，就会在内存中，不要每次都进行new操作。根据实验，即使是的程序关掉之后，仍然在内存中，下次只要是不关机，退出仍然在。我感觉奇怪，为什么的垃圾回收器没有将他们进行回收）回答： 因为在不同的类里，显示了，不同类的instance， 你要是用了 basesequencedao.instance 就应该没变化了。你后面的问题，我也遇到过，这个是犹豫，你的程序是在自己带的web应用容器里运行的，在任务栏里可以看到，你打开关闭了项目，但是 web应用服务器并没有关闭掉，导致一些缓存在web应用服务器的数据还是能保持原有数据，这个你关闭一下，重新调试时，数据 就没有了，很多人曾被这个搞得一头雾水，其中也包阔我嘿嘿。 、对于系统管理员或者一级管理员，用户配置权限，是否可以文字化的简单化的描述，便于你的软件的推广？、在程序中的,是否考虑实现groupby ,having的功能，微软的没有这个方法，但是我感觉是非常有用的。不知道在上是否有这个功能？、对于多表查询的语句，你在写程序的时候，是放入到层进行处理吗？这个长的语句你是分解成多个语句，等来写，还是组合成一个select的语句？、在程序中，基本是是针对数据库的类，有无计划扩展针对文件的类，或者从从网上的那个.net过来的类方法？、对于存储过程的写法，我以前用过李天平的代码生成工具，他把insert/delete/update全部用存储过程来自动生成，这样尤其在的时候，会少写很多参数，下次表要变化，只要重新生成一次存储过程，贴过来就可以了，我感觉他在这个几个存储过程中，有值得借鉴的地方，你可以看看他的产品，对比研究一下。3.实现通用权限模型3.1权限开发软件项目过程中，我们有单点登录规范、编码规范、数据库规范，类似权限模型，授权管理也是一个关键的规范之一，有统一的标准规范，在适当的环境适当的生产规模下，可以达到提高软件项目质量、促进生产率，更佳便于统一维护管理的目的。软件开发的现状，人员变动频繁，系统需要不断完善提高，而不是每年都推倒从来不利于积累及沉淀，劳民伤财反复建设不利于提高创新。3.1.1操作权限定义首先权限应该是可以灵活定义，想定义几个权限就可以定义几个权限，我们用树形结构来实现权限的定义。看图：权限应该可以无限制的灵活定义，才可以满足通用的需要，很多国内的产品，第一步设计权限时，就错了，不应该是固定的，表格列结构，这方面我们吃过很多亏，走了一些弯路，还有特别是模块+权限的设计，更是不可取的，灵活性与扩展性非常好。这是目前总结出来的，最好的权限设计结构，非常灵活，能满足比较复杂的应用情况。应该有，添加，编辑，删除，移动的功能，移动时要验证逻辑上是否允许引动，删除时，也要注意是否存在相关数据的关联性检查。特别要注意，要有比较灵活的排序功能。虽然权限为树形结构，但是不存在继承关系，也不存在相互间的依赖关系及关联关系，若采用这样的方式，系统的可维护性，通用性，复杂性将会提高。3.1.2操作权限维护权限的维护工作为集中模式管理，分布式开发，生产环境及测试环境分开实施比较理想化。由于权限系统是整个系统的核心系统，不应该分布是管理，建议用集中式管理，系统成熟后，这部分的配置变更相对会少一些。也能保证系统的稳定性。开发测试阶段，应该采用分布试开发环境比较稳妥，可以自己灵活测试，验证及配置权限。生产环境与开发环境采用不同的管理策略。3.1.3操作权限通常操作权限的逻辑表现为：什么人？ 是否有什么权限？页面操作表现为：是否有点击某个按钮的权限？3.1.4操作权限注意事项查看某列的权限，属于操作权限的一种特殊变种，表格里的权限，也应该按操作权限来处理。3.1.5列表型资源权限例子基础编码管理3.1.6树型资源权限例如组织机构本身，是一个树型资源的典型。3.1.7权限域3.1.8拒绝权限大部分人都有默认的权限，只有少部分人没有特定的权限时，可以采用拒绝权限来实现，这样可以大大减少权限的实施配质工作量，同时也会提高系统的整体性能。在权限实现上，不建议采用“允许权限、拒绝权限”方式处理，这样会容易增加系统的复杂性，而且权限配置上也会带来一些不直观的因素。建议采用拒绝权限也是一个权限，谁被赋予这个权限，就表明被拒绝拥有某项权限。3.1.9权限映射相同的软件产品在不同的客户实地实施过程中，往往会发现由于各客户的人员规模业务侧重点不同，实际工作中的权限需求的差异比较大，对权限的分配策略需求也各不相同。 后台简化管理策略 后台细化管理策略 例如我们在开发设计时划分了50 - 60个权限控制点，但是客户只想以5-6个权限控制点来控制整个系统的业务流转，方便权限分配管理操作，符合客户的实际需要。客户上线多个业务系统后，也会有统一授权管理的需要，希望从整体上，业务划分上，对系统权限配置进行整合，符合实际的工作任务划分的需要。系统上线后，客户在经营管理上的策略发生了变化、人员编制发生了变化、工作管理的细化程度发生了变化、业务的重点倾向发生了变化后，都希望权限系统能重新规划，希望能按客户的意愿进行后期调整。权限影射的控制点，可以分为2种，分别为为 权限客户端的映射路由、权限服务器端的映射路由，实际工作中推荐使用权限客户端的映射路由，可以对权限客户端进行灵活影射配置。3.2用户3.2.1用户权限逻辑图一个用户可以拥有多个权限，用户与权限之间的关联关系为1对多关系，整体关系表现为为多对多逻辑关系。对用户直接设置权限是日常生活中最便捷的操作，也是最灵活的，但是对系统规范的管理得角度，还是提倡权限先赋给角色，然后用户归属某些特定角色。用户权限管理参考界面3.2.2用户角色逻辑图一个用户可以归属于多个角色，用户与角色之间的关联关系为1对多关系，整体关系表现为为多对多逻辑关系。用户角色管理参考界面3.3用户默认角色实际工作中，用户通常是属于明确的一个角色中，一个用户可以在多个角色中，我们可以看做是一些特殊的需求，大部分，都是1个用户属于一个角色。3.3.1数据导入问题由于历史原因和工作环境中业系统的复杂性导致存在很多实际分布式的业务系统，经常会遇到各个系统间数据的导入导出需要，虽然用户与角色之间有1对多的关系，但是我们用默认1对1为主要处理模式，可以简化数据导入导出工作的复杂性及提高性能，极个别的数据，进行特殊处理就可以达到我们的最终目的。3.3.2实际需求软件开发人员，经常会犯过渡设计的错误，我们设计出的软件与实际需求不符合，操作配置过于复杂繁琐，在实施过程中经常会遇到这些哪些问题，有些我们可能设计得过于简单，有不能满足用户的实际需求。权限系统，应该能满足，简单的应用，由能满足比较复杂的应用是比较理想化的。应该针对不同的需求有不同的解决策略方案。3.4角色3.4.1用户-角色-权限3.4.2注意事项及原则一些比较初级的校验：角色名称不能重复，角色中的用户不能重复，角色名称不应该为空。角色不建议有子角色及继承关系，这样会使问题更加复杂化，与日常生活中的需求也不一样，在技术实现上也会增加复杂性，在权限实现上，也会带来性能问题。3.4.3角色分类角色不应该有继承关系，每个角色都是单独的，独立的个体（用户的群体），角色的继承等，过于负责，实际工作中实施及开发都不太实际。日常的操作系统及成熟的应用系统中，比较少见这样的继承管理，角色的继承会在很大程度上提高系统的复杂性，使系统不太容易实施，实现，影响运算性能，会失去系统的简单快捷性。角色与角色之间，可以有管理和被管理关系。不建议有继承关系。实际工作中的权限是由于工作岗位的不同，所拥有的职责权限也不同，明确的岗位编制应该有明确的责任权限。日常生活中的办事流程也应该是以岗位为基础设置工作流转的各个节点，而不应该是一个特定的人员。人员的流动是经常会发生变化，但是工作岗位是相对固定的，变化也比较少一些。人员变动了岗位是不变的，可以由另一个人接替工作。岗位是角色中的子集，是一群比较固定的，有明确编制的，有明确责任权限的用户群体。系统角色：管理维护软件系统的，特殊用户群体，例如开发人员，实施人员，维护人员等群体。临时用户组：是一群短暂生命周期的，由临时特殊需要而建立的用户群体，可以随意定义，随时撤消，对系统没有多大影响的用户群体。3.4.4角色权限关系角色权限应该是允许权限就可以了，有拒绝权限，影响系统的运行速度、运算性能，提高系统的复杂性，若遇到有拒绝权限的，可以按拆分角色或者按去掉所拥有的权限来实现就可以。3.4.5角色用户关系1个用户可以属于多个角色，1个角色里可以有多个用户。可以比较灵活的，将用户加入到某个角色，或者从某个角色将用户移除。应该有快速的查询功能，可以快速的移除一个用户，相应的，应该能有个比较高效的添加用户的功能，可以快速定位查询用户并将用户加入到指定的角色中。应该有排序功能，全选等功能，方便实用者实施。3.4.6操作权限实现参考权限大体上可以划分，操作权限及数据集权限（也叫资源权限）。很多人可能都有自己的权限实现，但是重复利用率是否高，运行速度是否最佳，想得是否周全等多方面考量一下，经得起考验的，应该也就不多了。权限最起码应该满足以下几点功能：01。权限可以随意定义，不能只是 新增、修改、删除，然后非常搞笑的再来个扩展1，扩展2，扩展3，这样的处理模式，应该是第一步就是走错了，权限元素可能都有上百，难道要来上百个字段表示？遇到另一个业务，权限又要重新设计过？由于业务性质的各不相同及客户侧重点的不同，同一个软件产品，在不同客户实施时，可能需要的权限需求都不一样。02。符合中国人的需求要“灵活”，权限可以直接赋值给用户，想给啥权限就给啥权限，来一个人，配置一下也可以，总共公司里就10个8个人，一年也变动的人员不是很多，不需要那么复杂的非要角色、岗位权限配置策略。03。当然也需要能灵活定义角色，然后给角色赋予权限，用户拉到角色里。04。权限判断的函数要稳定，格式明确，性能高，别判断个权限要好几秒钟才可以搞定。05。可以通过脚本设置权限，就像打dos命令一样，可以很方便的设置权限。06。权限如何用，应该有个比较简单易懂的例子程序，好让别人快速使用，我想这方面软件协会什么的，应该出个规范比较好。07。各个小公司的产品的框架都接近，买了多个小公司的产品，很容易集成在一起工作。08。权限是可以按客户的意愿可配置，可映射的，不应该是写死在程序里，可以灵活配置。09。权限应该是树状，三态的那种比较理想，上面的父节点一点，下面的权限自动都被选上了，设置起来很方便。10。权限配置的显示顺序也应该能设置，想让哪个权限优先显示，就让哪个权限优先显示。11 权限配置时还可以复制粘贴，能快速将权限配置给其他人或角色。以下sample, 供初学者参考。a.如何添加权限。b.如何删除权限。c.如何赋给用户权限。d.如何撤销用户的权限。e.如何添加角色。f.如何删除角色。g.如何赋给角色权限。h.如何撤销角色的权限。i.如何把用户添加到角色。j.如何把用户从角色中移除。k.检测用户的最终权限。3.5组织机构通常我们的行政管理模型，是以树形结构为主，并且是上级管理下级的逻辑组织。1个组织机构有一个明确的父节点，同时他可能有多个子细节点。3.5.1组织机构管理组织机构管理常用的功能，可以参考以上实例。3.5.2组织机构与用户管理建议一个用户默认属于一个组织机构，导入数据、导出数据、业务管理上，都会逻辑简单一些，若有1对多的实际关系存在，那还是要以满足实际需要为主。实例图中，companyid、departmentid 表示组织机构外键，公司的部门的归属关系。3.5.3组织机构与角色关系建议一个角色默认属于一个组织机构，若有1对多的实际关系存在，那还是要以满足实际需要为主。实例图中，organizeid 表示默认的组织机构外键。3.6分级授权、分级管理3.6.1分级授权由于业务系统的规模庞大，导致集中管理授权的工作量加大、以及工作细化、分布式的要求，导致很多系统需要即可以采用集中授权权限策略同时也能满足分级授权权限策略。用户所拥有的权限，可以理解为有2种，分别为，自身拥有的权限及用户可分配的权限，自身拥有的权限并不一定是用户可分配给其他人的权限，同样，可分配的权限，用户自己未必能直接拥有有这样的权限。例如软件系统的管理员，虽然有规划、分配全部系统的权限，但是他本人没有查看财务数据的权限、也没有查看人事薪资数据的权限。不可能由于他是系统的管理员就越权查看机密数据。（注超级管理员administrator 用户，administrators 组是软件系统开发公司的账户，他拥有所有的权限及不受权限域的限制，但是这个账号及角色，不适合在实际生产环境里应用实施）。角色拥有权限与可分配权限也是不一样的，拥有权限是自己本身的权限，而可分配权限是管理员可以分配给其他角色的权限，并不意味他自己拥有这些权限。用户的权限主要有4个部分组成：1：用户本身拥有的权限。2：用户所归属的角色拥有的权限。3：用户可授权的权限范围。4：用户的权限域。3.6.2分级管理实现分级管理实现，分2个部分，分别为：操作权限分级授权 及 权限域分级授权。3.6.3操作权限分级授权3.6.4权限域分级授权3.7权限域由于实际工作中的分工，产生了权限作用域的不同，例如设备处的管理员，有管理全校范围内分布在各处的设备信息的权限，但是没有全校范围内的财务管理权限，同样财务处的管理员，也没有管理全校范围内设备信息的权限，但是有管理财务信息的权限。虽然权限的范围相同的，都是全校的管理范围，但是权限是不一样的，一个是设备的管理权限域，另一个是财务的管理权限域。3.7.1权限域细化问题权限域划分得过于细腻，会在管理配置上带来不必要的麻烦，每个权限操作都设置为独立的权限域是不推荐的做法。尽量按业务来划分权限域比较好一些，实际分配权限时，操作也简便一些。过多的权限域也会开发人员测试人员带来没必要的麻烦，同样给最终用户也会带来很繁琐的权限域设置问题。例如每个权限都是权限域，那是不可取的做法。权限域的设置，与整个业务系统的显示数据模式、处理模式有密切关联关系的，不同的业务系统可以采用不同的权限域设置策略。3.7.2权限域叠加问题权限域划分过渡细腻后会导致权限域的叠加问题，例如：某个权限域的可修改的权限范围与此权限域的可删除的权限范围为不一样，可查看的权限域又不一样，那会导致程序上的逻辑判断复杂性等，页面显示逻辑的复杂性问题。会增加额外的负担，而且逻辑也会变得更乱，所以不建议将权限域划分得过于细腻。3.8模块菜单3.8.1模块管理3.8.2模块权限挂接3.8.3模块配置我们发布实施软件项目时，经常会遇到，某个客户要这些功能，那些功能不要，必须屏蔽，而且菜单里也不要显示，这时，我们希望我们的系统是可选配置的，后台管理员可以设定，启用哪些模块，哪些模块可以关闭掉。还有测试版时，我们希望只打开少部分功能，客户真正购买了我们的软件产品，才把客户已购买的功能模块开启。或者客户到了产品的使用期限，需要把一些模块进行关闭停止使用，当然敢这么做的开发商没几个，谁才是爷没搞清楚了不是。下面是我做的模块配置功能，很简单，打沟了，这个模块就打开了，关闭了在前台就看不到了，说起来简单，实现起来，也的确不容易，经过了很长时间的锤炼，才渐渐的稳定起来了，因为开发的所有模块都必须要遵循这个规则，要把以前开发的模块都需要进行改良才能前台与后台保持一致。还需要考虑好，各个模块的独立性，停止了某些模块，其他模块还能正常运行才可以。 参考页面如下：当然有理想的，安装模块、卸载模块、启用、停用功能是最理想的。3.9标准日志整个系统应该能提供标准日志记录功能，但是考虑到性能问题，可以关闭日常的日志功能，但是一些与系统安全密切相关的动作，应该是强制性的写入日志。日志应该有导出功能比较友善些。3.9.1访问情况3.9.2按用户查询3.9.3按模块查询3.9.4按日期查询3.10等同权限3.11帐号扮演3.12委托代理3.13大规模多业务授权实施策略集中权限分配策略分各业务子系统权限分配策略4.权限规范实际应用4.1数据结构直接引用目前参与浙大项目的软件开