1.权限设计概述

1.1引言

随着Web 服务的复杂度增加以及用户数量和种类的增多，安全问题在理论及工程上都

是一个必须考虑的问题，而权限管理是安全问题中一个很重要的方面。因此本文针对权限做

了一个分析。

权限可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的

逻辑表达式是否为真。

1.2意义

❖用户管理及权限管理一直是应用系统中不可缺少的一个部分

❖系统用户很多，系统功能也很多

❖不同用户对系统功能的需求不同

❖出于安全等考虑，关键的、重要的系统功能需部分用户的使用

❖出于方便性考虑，系统功能需要根据不同的用户而定制

1.3目标

直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，

除了功能的必须，更主要的就是因为它足够直观。

简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解

决所有的权限问题是不现实的。设计中将变化的“定制”特点比较强的部分判断为业务逻辑，

而将相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

扩展，采用可继承的方式解决了权限在扩展上的困难。引进Group概念在支持权限以组

方式定义的同时有效避免了权限的重复定义。

2.基于角色的权限管理设计（Role-Based Access Control,RBAC）2.1权限管理用例图

2.2用例图描述

超级管理员：系统中默认的角色，它是系统中拥有最高权限的角色，它不仅能够管理其他的管理员和用户，而且还可以对系统中每个模块的任一功能进行操作、维护。

普通管理员：它是由超级管理员创建的，并授予权限，它能够管理系统部分的功能，它可以查看所有普通管理员、普通用户的信息，它只能对由它自己创建的用户进行编辑、删除操作，和管理拥有权限的模块。

普通用户：它是系统中最低权限的角色，它只能对自己拥有的权限进行操作，一般情况下，它的权限是对信息的浏览和对自己信息的录入，修改。

登陆系统：根据用户拥有的权限不同，用户所能操作的功能多少就不同，所以在登陆系统的时候就要对用户的权限进行判断。

用户管理：这里对本系统的登录用户进行维护。包括，新建、删除、编辑、注销等；系统初始化的时候，用户管理中默认只有一个拥有超级管理员角色的用户，因此在初始化登陆的时候，只能用这个用户登陆，其他的用户由这个用户创建并授予角色。

角色管理：角色是赋予系统用户的职权名称。包括，新建、删除、编辑、注销等；系统初始化的时候，角色管理中默认只拥有一个超级管理员的角色，其他角色由拥有这个角色的用户创建并授权。

其他模块：其他模块的每个功能都拥有一个唯一Id，根据用户登陆的权限，再确定这些功能是否对用户开放。

3.权限设计思路

3.1 基于角色的访问控制RBAC

RBAC 的主要思想是:权限（Permissions）是和角色（Roles）相联系的，而用户（Users）则被指定到相应的角色作为其成员。这样就使权限的管理大大简化了。

系统的权限控制主要是采用基于角色的访问控制，把权限绑定到角色上，当用户要操作权限时，就把角色赋给用户。而且在需要撤回权限时，只需把角色上的权限撤回就行了。

3.2思路

为了设计一套具有较强可扩展性的权限管理，需要建立用户、角色和权限等数据库表，并且建立之间的关系，具体实现如下

3.3 用户

用户仅仅是纯粹的用户，用来记录用户相关信息，如用户名、密码等，权限是被分离出去了的。用户（User）要拥有对某种资源的权限，必须通过角色（Role）去关联。用户通常具有以下属性：

编号，在系统中唯一。

名称，在系统中唯一。

用户口令。

注释，描述用户或角色的信息。

3.4 角色

角色是使用权限的基本单位，拥有一定数量的权限，通过角色赋予用户权限，通常具有以下属性：

编号，在系统中唯一。

名称，在系统中唯一---- (监控人员)注释，描述角色信息. ---→(在线监控人员)

3.5 权限

权限指用户根据角色获得对程序某些功能的操作，例如对文件的读、写、修改和删除功能，通常具有以下属性：

编号，在系统中唯一。

名称，在系统中唯一-----→(添,删,改,查)

注释，描述权限信息.---→允许增加监控对象

3.6 用户与角色的关系

一个用户（User）对应一个角色（Role），一个角色可以被多个用户使用，用户角色就是用来描述他们之间隶属关系的对象。用户（User）通过角色（Role）关联所拥有对某种资源的权限，例如

用户（User）：

UserID UserName UserPwd

1 三 xxx xxx

2 四 xxx xxx

……

角色（Role）：

RoleID(角色编号) RoleName(角色名

称) RoleNote(角色注释)

01 系统管理

员监控系统维护管理员

02 监控人

员在线监控人员

03 调度人

员调度工作人员

04 一般工作人员

工作人员

……

用户角色（User_Role）：

UserRoleID UserID RoleID UserRoleNote( 用户角色注释)

1 1

02 用户“三”被分配到角色“监控人员”

2 2

02 用户“四”被分配到角色“监控人员”

……

从该关系表可以看出，用户所拥有的特定资源可以通过用户角色来关联。

3.7 权限与角色的关系

一个角色（Role）可以拥有多个权限（Permission），同样一个权限可分配给多个角色。

例如：

角色（Role）：

RoleUUID(角色UUID) RoleName(角色名

称) RoleRemark(角色注释)

01 系统管理

员监控系统维护管理员

02 监控人

员在线监控人员

03 调度人

员调度工作人员

04 一般工作人员

工作人员

……

权限（Privilege）：

PrivilegeUUID(权限UUID) PrivilegeName(权限名

称) PrivilegeRemark(权限注释)

0001 增加监

控允许增加监控对象

0002 修改监

控允许修改监控对象

0003 删除监

控允许删除监控对象

0004 察看监控信

息允许察看监控对象

角色权限（Role_ Privilege）：

RolePermissionID RoleUUID PrivilegeUUID Role_PrivilegeRemark(角色权限注释)

1 01

0001 角色“系统管理员”具有权限“增加监控”

2 01

0002 角色“系统管理员”具有权限“修改监控”

3 01

0003 角色“系统管理员”具有权限“删除监控”

4 01

0004 角色“系统管理员”具有权限“察看监控”

5 02

0001 角色“监控人员”具有权限“增加监控”

6 02

0004 角色“监控人员”具有权限“察看监控”……

由以上例子中的角色权限关系可以看出，角色权限可以建立角色和权限之间的对应关系。

3.8 建立用户权限

用户权限系统的核心由以下三部分构成：创造权限、分配权限和使用权限。

第一步由Creator创造权限（Permission），Creator在设计和实现系统时会划分，指定系统模块具有哪些权限。

第二步由系统管理员（Administrator）创建用户和角色，并且指定用户角色（User－Role）和角色权限（Role－Permission）的关联关系。

第三步用户（User）登陆系统，对自己拥有的权限进行管理、使用。

4.权限的具体实现模式

模式一：用户->角色->权限（最通用的方法）

4.1 数据库结构

4.1.1用户表：

4.1.2角色表：

4.1.3权限表：

4.2 在控制层写if/else判断条件

用户登入系统后，就通过其角色加载所有可以访问的页面，保存到Session, 一直到用户退出系统或者session 过期。用户访问页面时，添加一个Dispatcher （tape stry5 方式），在这个Dispatcher中解析出页面地址如/cs/deposit ，和用户保存在Session 里的可访问页面作比较，如果存在则继续，不存在则跳到登入页面。

模式二：Ralasafe第三方组件（图形界面的形式，简单易用）

安装、配置与使用手册：.ralasafe.cn/downloads/Ralasafe_Configuration_zh.pdf Ralasafe，是采用Java语言开发的轻量级数据级权限管理中间件。解开权限与业务的耦合，采用全景式、图形化管理方式，无需大量Java和XML开发配置。

Ralasafe将权限分为两大类

查询权限：用户从系统获取数据，此时系统根据用户不同，返回该用户具有权限查询的数据决策权限：用户向系统提交操作数据（如：修改、添加或者删除某订单），此时系统根据用户和被操作数据，判断是否允许操作

权限层级分为两大类

功能级权限，又称操作权限，使用角色模型足够

数据级权限，支持数据行级、列级，又称容权限，细粒度权限

Ralasafe专注于数据级权限，使用策略机制进行管理。Ralasafe也提供了功能级权限实现，该功能可选，并不耦合。

Ralasafe系统架构

安全引擎，该引擎解析授权策略，对所有访问进行过滤。从2个方向进行控制：

从系统获取数据，比如查询订单，查询客户资料

向系统提交数据，比如修改某订单，删除某客户资料

管理界面，通过管理界面IT管理员可以轻松管理、设计授权策略，并在线仿真测试。

Ralasafe是服务，而不是框架。对应用程序没有要求，也不需要修改业务数据库。Ralasafe的结构性数据与业务数据保存在数据库，非结构性数据保存在文件系统，方便移植。

模式三：注解和实现权限通用模型的设计

使用这种设计方案，可以很好地分离权限与系统本身的功能，让开发过程更加关注系统的核心功能，同时可以很容易做到开发时的任务划分，同时使项目代码的可读性大大提升。

权限模型的常量定义：

一个系统里最常见的需求莫过于权限、角色，我们需要两个类，一个表明都有什么权限（例如：删除帖子权限、编辑帖子权限，等等）;另一个类表明，各个角色都有什么权限。这样子相当于定义了一个权限和角色模型。

与注解：

（Invocation）在在流行的开源框架中很常见，依赖的技术就是Java的动态代理。许多流行的框架都提供实现的接口，可以很简单就实现一个，此文不表如何实现。注解（Annotations）是JAVA在5.0后引入的特性，它引入的目的是为了替代一些简单的配置到java代码里，而不用原来的xml。

注解请求示例：

一般的框架，都会有一个controller类，以下用伪代码表示：

public class ThreadsController{

PriCheckRequired({MemberPrivilegeIdentity.CREATE_THREAD})

public String createThread(){

return "createThread";

}

可以想像在里要做的事情：

一般都是实现一个框架提供的接口来实现，常用框架都支持。

1.根据规定好的request请求的参数，取到用户属于哪个角色。

2.根据controller中注解，取到当前要判断的权限。

3.对比用户角色是否有注解中的权限，如果有，放行，反之拦截。

具体的实现过程：

的代码实现与框架有关:rose框架如何实现请看

code.google./p/paoding-rose/wiki/Rose_Code_Fragment_Interceptor

模式四：基于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(this.permission)){

if (template.equals("text") || template.equals("radio") || template.equals("checkbox") || template.equals("textarea")){template = "labelhidden";

}

if (template.equals("select")){

template = "hidden4select";

}

}

也就是说，在只读权限时，我们直接替掉webwork默认的freemarker模板，自己写一个freemarker模板下载本文