完整的权限管理系统,你有这样完整权限的设计吗?
2013-10-08 12:07
387 查看
很多人都知道以角色为基础的权限管理设计(RBAC),但是大部分人似懂非懂,不知道完整的权限管理系统都包括哪些内容。
在此以权限管理的使用场景来说明一下完整的权限管理内容。
一是鉴权管理,即权限判断逻辑。
1. 最基本的权限管理就是菜单管理,用户没有权限的功能模块在菜单节点上是不显示的。(很多人以为这就是权限管理!)
示例:普通业务人员登录系统后,是看不到【用户管理】菜单的。
2. 功能权限管理,B/S系统的功能体现为URL,所以功能权限管理主要是针对URL访问的管理。(很多人都不清楚权限管理的对象是什么?)
示例:
经过授权,部门经理可以查看【用户管理】菜单,并查看部门用户信息,但权限设计要求,该部门经理没有添加用户的权限。
所以在访问【添加用户】的功能(URL)时,应该有没有授权的提示信息。
同时在【用户管理】页面上,【添加用户】的按钮应该灰色显示,不能点击。
3. 行级权限管理
示例:
论坛管理员,权限设计要求 A能管理论坛 【新闻版块】,不能管理论坛 【技术交流】
此时的权限设计就应该根据论坛的相应ID来判断权限信息。
4. 列级权限管理
示例:
业务权限设计要求,除销售人员以外,其他用户不能看到客户的联系方式信息。
此时的权限设计要判断相应的字段(列)是否可以显示。
5. 组织机构/部门级数据权限管理
示例:
业务权限设计要求,销售一部的人员只能看到本部门的销售订单,销售二部的人员只能看到本部门的销售订单,但销售经理可以同时看到
销售一部和销售二部的销售订单。
此时的权限设计就要根据销售订单数据本身的部门属性来做判断
6. 范围型业务数据权限管理
示例:
大卖场销售人员在下销售订单时,要选择相应的产品所在仓库信息。
业务权限设计要求,【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】,而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】
二是授权管理,即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户,授权功能应该足够灵活。
1. 直接对用户授权,直接分配到用户的权限具有最优先级别。
2. 对用户所属岗位授权,用户所属岗位信息可以看作是一个分组,和角色的作用一样,但是每个用户只能关联一个岗位信息。
3. 对用户所属角色授权,用户所属角色信息可以看作是一个权限分组,每个用户可以关联多个角色。
4. 角色直接关联具体的功能权限(URL),也可以关联负权限,即此角色关联的权限不能使用负权限功能。负权限具有优先级别。
5. 分级授权,系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。
以上才是一个完整的权限管理系统,你有这样的完整权限的设计吗?
在此以权限管理的使用场景来说明一下完整的权限管理内容。
一是鉴权管理,即权限判断逻辑。
1. 最基本的权限管理就是菜单管理,用户没有权限的功能模块在菜单节点上是不显示的。(很多人以为这就是权限管理!)
示例:普通业务人员登录系统后,是看不到【用户管理】菜单的。
2. 功能权限管理,B/S系统的功能体现为URL,所以功能权限管理主要是针对URL访问的管理。(很多人都不清楚权限管理的对象是什么?)
示例:
经过授权,部门经理可以查看【用户管理】菜单,并查看部门用户信息,但权限设计要求,该部门经理没有添加用户的权限。
所以在访问【添加用户】的功能(URL)时,应该有没有授权的提示信息。
同时在【用户管理】页面上,【添加用户】的按钮应该灰色显示,不能点击。
3. 行级权限管理
示例:
论坛管理员,权限设计要求 A能管理论坛 【新闻版块】,不能管理论坛 【技术交流】
此时的权限设计就应该根据论坛的相应ID来判断权限信息。
4. 列级权限管理
示例:
业务权限设计要求,除销售人员以外,其他用户不能看到客户的联系方式信息。
此时的权限设计要判断相应的字段(列)是否可以显示。
5. 组织机构/部门级数据权限管理
示例:
业务权限设计要求,销售一部的人员只能看到本部门的销售订单,销售二部的人员只能看到本部门的销售订单,但销售经理可以同时看到
销售一部和销售二部的销售订单。
此时的权限设计就要根据销售订单数据本身的部门属性来做判断
6. 范围型业务数据权限管理
示例:
大卖场销售人员在下销售订单时,要选择相应的产品所在仓库信息。
业务权限设计要求,【国美】的销售人员在选择仓库的下拉列表中不能看到【广州仓库】,而【大中电器】的销售人员在选择仓库的下拉列表中不能看到【北京顺义仓库】
二是授权管理,即权限分配过程。以上的权限管理内容都要通过系统的授权功能来分配给具体的用户,授权功能应该足够灵活。
1. 直接对用户授权,直接分配到用户的权限具有最优先级别。
2. 对用户所属岗位授权,用户所属岗位信息可以看作是一个分组,和角色的作用一样,但是每个用户只能关联一个岗位信息。
3. 对用户所属角色授权,用户所属角色信息可以看作是一个权限分组,每个用户可以关联多个角色。
4. 角色直接关联具体的功能权限(URL),也可以关联负权限,即此角色关联的权限不能使用负权限功能。负权限具有优先级别。
5. 分级授权,系统管理员可以将自己拥有的权限信息授权给其他用户。即可以设置分级管理员和超级管理员。
以上才是一个完整的权限管理系统,你有这样的完整权限的设计吗?
相关文章推荐
- 完整的权限管理系统,你有这样完整权限的设计吗?
- 设计完整的权限管理系统<非原创>
- 权限管理系统概要设计
- 实现业务系统中的用户权限管理--设计篇(强烈推荐)
- 在EF的code frist下写稳健的权限管理系统:仓储设计(三)
- 模块管理常规功能自定义系统的设计与实现(05--权限和菜单)
- 实现业务系统中的用户权限管理--设计篇
- 通用数据权限管理系统设计(一)
- 【通用权限管理】角色的分类管理,角色-用户组-职位职务-系统角色的设计上的迷惑也解开
- (转)ASP.NET MVC4+EasyUI+EntityFrameWork权限管理系统——数据库的设计(一)
- 如何在自己的信息管理系统里集成第三方权限控制组件 - 设计一个漂亮的WEB界面
- 通用数据权限管理系统设计
- (转)OA系统权限管理设计方案
- 通用的权限管理系统的设计
- 实现业务系统中的用户权限管理--设计篇
- 设计权限管理系统(一)
- 用户和角色:通用权限管理系统数据库表结构如何设计?
- 权限管理系统(偏重于数据库设计)
- 基于RBAC模型的权限管理系统的设计和实现
- 实现业务系统中的用户权限管理--设计篇