权限管理设计Word文档下载推荐.docx
《权限管理设计Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《权限管理设计Word文档下载推荐.docx(13页珍藏版)》请在冰点文库上搜索。
普通用户:
它是系统中最低权限的角色,它只能对自己拥有的权限进行操作,一般情况下,它的权限是对信息的浏览和对自己信息的录入,修改。
登陆系统:
根据用户拥有的权限不同,用户所能操作的功能多少就不同,所以在登陆系统的时候就要对用户的权限进行判断。
用户管理:
这里对本系统的登录用户进行维护。
包括,新建、删除、编辑、注销等;
系统初始化的时候,用户管理中默认只有一个拥有超级管理员角色的用户,因此在初始化登陆的时候,只能用这个用户登陆,其他的用户由这个用户创建并授予角色。
角色管理:
角色是赋予系统用户的职权名称。
系统初始化的时候,角色管理中默认只拥有一个超级管理员的角色,其他角色由拥有这个角色的用户创建并授权。
其他模块:
其他模块的每个功能都拥有一个唯一Id,根据用户登陆的权限,再确定这些功能是否对用户开放。
3.权限设计思路
基于角色的访问控制RBAC
RBAC的主要思想是:
权限(Permissions)是和角色(Roles)相联系的,而用户(Users)则被指定到相应的角色作为其成员。
这样就使权限的管理大大简化了。
系统的权限控制主要是采用基于角色的访问控制,把权限绑定到角色上,当用户要操作权限时,就把角色赋给用户。
而且在需要撤回权限时,只需把角色上的权限撤回就行了。
思路
为了设计一套具有较强可扩展性的权限管理,需要建立用户、角色和权限等数据库表,并且建立之间的关系,具体实现如下
用户
用户仅仅是纯粹的用户,用来记录用户相关信息,如用户名、密码等,权限是被分离出去了的。
用户(User)要拥有对某种资源的权限,必须通过角色(Role)去关联。
用户通常具有以下属性:
编号,在系统中唯一。
名称,在系统中唯一。
用户口令。
注释,描述用户或角色的信息。
角色
角色是使用权限的基本单位,拥有一定数量的权限,通过角色赋予用户权限,通常具有以下属性:
名称,在系统中唯一----(监控人员)
注释,描述角色信息.---(在线监控人员)
权限
权限指用户根据角色获得对程序某些功能的操作,例如对文件的读、写、修改和删除功能,通常具有以下属性:
名称,在系统中唯一-----(添,删,改,查)
注释,描述权限信息.---允许增加监控对象
用户与角色的关系
一个用户(User)对应一个角色(Role),一个角色可以被多个用户使用,用户角色就是用来描述他们之间隶属关系的对象。
用户(User)通过角色(Role)关联所拥有对某种资源的权限,例如
用户(User):
UserIDUserNameUserPwd
1张三xxxxxx
2李四xxxxxx
……
角色(Role):
RoleID(角色编号)RoleName(角色名称)RoleNote(角色注释)
01系统管理员监控系统维护管理员
02监控人员在线监控人员
03调度人员调度工作人员
04一般工作人员工作人员
……
用户角色(User_Role):
UserRoleIDUserIDRoleIDUserRoleNote(用户角色注释)
1102用户“张三”被分配到角色“监控人员”
2202用户“李四”被分配到角色“监控人员”
从该关系表可以看出,用户所拥有的特定资源可以通过用户角色来关联。
权限与角色的关系
一个角色(Role)可以拥有多个权限(Permission),同样一个权限可分配给多个角色。
例如:
角色(Role):
RoleUUID(角色UUID)RoleName(角色名称)RoleRemark(角色注释)
01系统管理员监控系统维护管理员
02监控人员在线监控人员
03调度人员调度工作人员
04一般工作人员工作人员
权限(Privilege):
PrivilegeUUID(权限UUID)PrivilegeName(权限名称)PrivilegeRemark(权限注释)
0001增加监控允许增加监控对象
0002修改监控允许修改监控对象
0003删除监控允许删除监控对象
0004察看监控信息允许察看监控对象
角色权限(Role_Privilege):
RolePermissionIDRoleUUIDPrivilegeUUIDRole_PrivilegeRemark(角色权限注释)
1010001角色“系统管理员”具有权限“增加监控”
2010002角色“系统管理员”具有权限“修改监控”
3010003角色“系统管理员”具有权限“删除监控”
4010004角色“系统管理员”具有权限“察看监控”
5020001角色“监控人员”具有权限“增加监控”
6020004角色“监控人员”具有权限“察看监控”
由以上例子中的角色权限关系可以看出,角色权限可以建立角色和权限之间的对应关系。
建立用户权限
用户权限系统的核心由以下三部分构成:
创造权限、分配权限和使用权限。
第一步由Creator创造权限(Permission),Creator在设计和实现系统时会划分,指定系统模块具有哪些权限。
第二步由系统管理员(Administrator)创建用户和角色,并且指定用户角色(User-Role)和角色权限(Role-Permission)的关联关系。
第三步用户(User)登陆系统,对自己拥有的权限进行管理、使用。
4.权限的具体实现模式
模式一:
用户->
角色->
权限(最通用的方法)
数据库结构
用户表:
表名:
user_control_tab
含义:
用户表
字段
名称
类型
字段长度
是否是关键字
是否为空
含义
说明
id
bigint
8
是
否
编号
主键,自增
uuid
binary
16
UUID
唯一
role_uuid
角色UUID
对应角色表的UUID
user_name
varchar
用户名
只能是数字,字母,下划线组成
user_pwd
密码
密码的长度在6-16个字符之间
real_name
6
真实姓名
要求填写用户真实姓名
sex
int
2
性别
0:
男1:
女
phone
11
移动电话
用户的手机号码
email
100
邮箱
用户的邮箱
remark
备注
角色表:
role_tab
角色表
role_name
角色名称
权限表:
privilege_tab
权限表
是否
为空
pri_name
权限名称
ext_id
功能id
页面功能的id,唯一
角色权限表:
role_privilege_tab
角色权限表表
引用角色表的UUID,唯一
pri_uuid
权限UUID
引用权限表的UUID,唯一
在控制层写if/else判断条件
用户登入系统后,就通过其角色加载所有可以访问的页面,保存到Session,一直到用户退出系统或者session过期。
用户访问页面时,添加一个Dispatcher(tapestry5方式),在这个Dispatcher中解析出页面地址如/cs/deposit,和用户保存在Session里的可访问页面作比较,如果存在则继续,不存在则跳到登入页面。
模式二:
Ralasafe第三方组件(图形界面的形式,简单易用)
安装、配置与使用手册:
Ralasafe,是采用Java语言开发的轻量级数据级权限管理中间件。
解开权限与业务的耦合,采用全景式、图形化管理方式,无需大量Java和XML开发配置。
Ralasafe将权限分为两大类
查询权限:
用户从系统获取数据,此时系统根据用户不同,返回该用户具有权限查询的数据
决策权限:
用户向系统提交操作数据(如:
修改、添加或者删除某订单),此时系统根据用户和被操作数据,判断是否允许操作
权限层级分为两大类
功能级权限,又称操作权限,使用角色模型足够
数据级权限,支持数据行级、列级,又称内容权限,细粒度权限
Ralasafe专注于数据级权限,使用策略机制进行管理。
Ralasafe也提供了功能级权限实现,该功能可选,并不耦合。
Ralasafe系统架构
安全引擎,该引擎解析授权策略,对所有访问进行过滤。
从2个方向进行控制:
从系统获取数据,比如查询订单,查询客户资料
向系统提交数据,比如修改某订单,删除某客户资料
管理界面,通过管理界面IT管理员可以轻松管理、设计授权策略,并在线仿真测试。
Ralasafe是服务,而不是框架。
对应用程序没有要求,也不需要修改业务数据库。
Ralasafe的结构性数据与业务数据独立保存在数据库,非结构性数据保存在文件系统,方便移植。
模式三:
注解和拦截器实现权限通用模型的设计
使用这种设计方案,可以很好地分离权限与系统本身的功能,让开发过程更加关注系统的核心功能,同时可以很容易做到开发时的任务划分,同时使项目代码的可读性大大提升。
权限模型的常量定义:
一个系统里最常见的需求莫过于权限、角色,我们需要两个类,一个表明都有什么权限(例如:
删除帖子权限、编辑帖子权限,等等);
另一个类表明,各个角色都有什么权限。
这样子相当于定义了一个权限和角色模型。
拦截器与注解:
拦截器(Invocation)在在流行的开源框架中很常见,依赖的技术就是Java的动态代理。
许多流行的框架都提供实现拦截器的接口,可以很简单就实现一个拦截器,此文不表如何实现。
注解(Annotations)是JAVA在后引入的特性,它引入的目的是为了替代一些简单的配置到java代码里,而不用原来的xml。
注解请求示例:
一般的框架,都会有一个controller类,以下用伪代码表示:
publicclassThreadsController{
@PriCheckRequired({})
publicStringcreateThread(){
return"
createThread"
;
}
如代码中所示,一个controller里的一个method对应一个URL请求(例中所示为创建帖子)。
我们只需要在其方法上标注@PriCheckRequired({}),PriCheckRequired就是注解,其传递了一个信息,这也就是前文说的权限类中的创建帖子权限。
可以想像在拦截器里要做的事情:
拦截器一般都是实现一个框架提供的接口来实现,常用框架都支持。
1.根据规定好的request请求的参数,取到用户属于哪个角色。
2.根据controller中注解,取到当前要判断的权限。
3.对比用户角色是否有注解中的权限,如果有,放行,反之拦截。
具体的实现过程:
拦截器的代码实现与框架有关:
rose框架如何实现拦截器请看
模式四:
基于webwork和过滤器实现无代码侵入的原子级界面权限
修改webwork的基类UIBean来实现页面的权限控制:
1、首先将页面的权限定义保存到数据库或xml的配置文件中;
2、编写一个监听器LoadPagePermissionListener来从权限的描述文件中,加载权限信息到缓存;
3、编写页面权限过滤器,例如PagePermissionFilter,实现对页面请求的过滤;
4、当用户请求一个web表单时,首先通过.action去请求,此时.action被PagePermissionFilter过滤器拦截到,此过滤器中从用户所请求的web表单对应的XML权限描述文件或数据库中取得此web表单中所有HTML控件的权限集合,并将此集合传递给webwork的控制器,最后到webwork的HTML控件生成器的父类UIBean,由UIBean去render我们请求的表单中的所有HTML控件,这render之前,我们通过改写这个UIBean,使其在render每个控件之前,先从我们的权限集合中取出这个控件的权限(可编辑、只读、可视、不可视)进行设定,然后根据设定的权限进行渲染,最后我们看到的就是一个经过权限过滤的界面了,并且这个表单对于用户完全是透明的,开发人员不用添加任何关于表单控件权限的代码!
5、由于webwork对于Select框、radio框、checkbox框等的只读显示状态并不能满足用户的需求,例如对于select框,用户要求只读状态时,不显示边框,只显示实际的字段值,见如下代码:
if("
readonly"
.equals){
if("
text"
)||("
radio"
checkbox"
textarea"
)){
template="
labelhidden"
}
select"
hidden4select"
也就是说,在只读权限时,我们直接替掉webwork默认的freemarker模板,自己写一个freemarker模板