权限管理设计.docx
《权限管理设计.docx》由会员分享，可在线阅读，更多相关《权限管理设计.docx（13页珍藏版）》请在冰点文库上搜索。
权限管理设计
对EMS权限管理模块设计
1.权限设计概述
引言
随着Web服务的复杂度增加以及用户数量和种类的增多，安全问题在理论及工程上都是一个必须考虑的问题，而权限管理是安全问题中一个很重要的方面。
因此本文针对权限做了一个分析。
权限可简单表述为这样的逻辑表达式：
判断“Who对What（Which）进行How的操作”的逻辑表达式是否为真。
意义
用户管理及权限管理一直是应用系统中不可缺少的一个部分
系统用户很多，系统功能也很多
不同用户对系统功能的需求不同
出于安全等考虑，关键的、重要的系统功能需限制部分用户的使用
出于方便性考虑，系统功能需要根据不同的用户而定制
目标
直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，除了功能的必须，更主要的就是因为它足够直观。
简单，包括概念数量上的简单和意义上的简单还有功能上的简单。
想用一个权限系统解决所有的权限问题是不现实的。
设计中将变化的“定制”特点比较强的部分判断为业务逻辑，而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。
扩展，采用可继承的方式解决了权限在扩展上的困难。
引进Group概念在支持权限以组方式定义的同时有效避免了权限的重复定义。
2.基于角色的权限管理设计（Role-BasedAccessControl,RBAC）
权限管理用例图
用例图描述
超级管理员：
系统中默认的角色，它是系统中拥有最高权限的角色，它不仅能够管理其他的管理员和用户，而且还可以对系统中每个模块的任一功能进行操作、维护。
普通管理员：
它是由超级管理员创建的，并授予权限，它能够管理系统中大部分的功能，它可以查看所有普通管理员、普通用户的信息，它只能对由它自己创建的用户进行编辑、删除操作，和管理拥有权限的模块。
普通用户：
它是系统中最低权限的角色，它只能对自己拥有的权限进行操作，一般情况下，它的权限是对信息的浏览和对自己信息的录入，修改。
登陆系统：
根据用户拥有的权限不同，用户所能操作的功能多少就不同，所以在登陆系统的时候就要对用户的权限进行判断。
用户管理：
这里对本系统的登录用户进行维护。
包括，新建、删除、编辑、注销等；系统初始化的时候，用户管理中默认只有一个拥有超级管理员角色的用户，因此在初始化登陆的时候，只能用这个用户登陆，其他的用户由这个用户创建并授予角色。
角色管理：
角色是赋予系统用户的职权名称。
包括，新建、删除、编辑、注销等；系统初始化的时候，角色管理中默认只拥有一个超级管理员的角色，其他角色由拥有这个角色的用户创建并授权。
其他模块：
其他模块的每个功能都拥有一个唯一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
binary
16
否
角色UUID
对应角色表的UUID
user_name
varchar
16
否
用户名
只能是数字，字母，下划线组成
user_pwd
varchar
16
否
密码
密码的长度在6-16个字符之间
real_name
varchar
6
否
真实姓名
要求填写用户真实姓名
sex
int
2
否
性别
0：
男1：
女
phone
bigint
11
否
移动电话
用户的手机号码
email
varchar
100
否
邮箱
用户的邮箱
remark
varchar
100
是
备注
角色表：
表名：
role_tab
含义：
角色表
字段
名称
字段
类型
字段长度
是否是关键字
是否为空
字段
含义
字段
说明
id
bigint
8
是
否
编号
主键，自增
uuid
binary
16
否
UUID
唯一
role_name
varchar
16
否
角色名称
只能是数字，字母，下划线组成
remark
varchar
100
备注
权限表：
表名：
privilege_tab
含义：
权限表
字段
名称
字段
类型
字段长度
是否是关键字
是否
为空
字段
含义
字段
说明
id
bigint
8
是
否
编号
主键，自增
uuid
binary
16
否
UUID
唯一
pri_name
varchar
16
否
权限名称
只能是数字，字母，下划线组成
ext_id
varchar
100
否
功能id
页面功能的id，唯一
remark
varchar
100
备注
角色权限表：
表名：
role_privilege_tab
含义：
角色权限表表
字段
名称
字段
类型
字段长度
是否是关键字
是否
为空
字段
含义
字段
说明
id
bigint
8
是
否
编号
主键，自增
role_uuid
binary
16
否
角色UUID
引用角色表的UUID，唯一
pri_uuid
binary
16
否
权限UUID
引用权限表的UUID，唯一
remark
varchar
100
备注
在控制层写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";
}
if（"select"））{
template="hidden4select";
}
}
也就是说，在只读权限时，我们直接替掉webwork默认的freemarker模板，自己写一个freemarker模板
升级会员 