1. 需求分析

某公司要求设计出一个公司内部的一个资源管理系统。需求如下：

1. 公司内部分有总经理，产品经理，每个产品生产线下又分为财务，质监，生产，销售员工，之下又有产品生产线普通员工和公司的基础员工等，每个员工都有自己的权限，可以查看或修改相应的文件。

2.用户权限在层次上到下依次递减。

3. 每个用户可以拥有多个职位，但为了保密，用户不能同时拥有两个不同产品的生产线的职位。作为总经理虽然拥有两个生产线的的权限，不能在一次登录中同时查看两个生产线的文件。

4. 系统还应该设有管理员用户，管理员也分为公司主管，高级主管，两个产品的主管等，每个主管有不同的权限，其中在授予用户的职位时，每个主管有自己的授权范围。而在回收用户的职位时，主管在层次上到下的权限依次递减。

2. 访问控制系统设计原则

基于以上的需求，我们使用了访问控制中的基于角色的访问控制——RBAC。

其中设计的用户角色层次如下图2-1所示：

图2-1

管理员层次结构图如下图2-2所示：

图2-2

根据以上设计的公司内部用户角色和管理员角色的层次图以及需求分析，我们使用以下的RBAC规则。

静态职责分离原则：在用户被分配了1产品生产线的角色之后，就不能再被分配任何2产品生产线上的任何角色。

动态职责分离原则：由于存在总经理这样一个角色，就使这个角色既能使用1产品生产线上的资源，又能使用2产品生产线上的资源。这样就使用动态职责分离这样一个原则，使每次登陆看做是一个session，在每个session中，总经理这个角色只能访问同一个生产线上的资源。

其中用户——角色——权限实现了RBAC3，效果如下图2-3所示：

图2-3

管理员方面则是实现了URA97: 用户—角色的管理，一个用户指派到一个相应的角色中，以及从一个角色中回收一个用户的成员资格。

3. 访问控制系统框架设计

3.1 在应用系统中的位置

对于该系统，我们的设计是对以下的txt文档的读写来完成用户对资源的模拟。如下图3-1所示：

图3-1

1产品资料中有以下文件。如下图3-2所示：

图3-2

普通用户通过登陆进入系统后，可以执行查看功能选择以上的资料，点击查看按钮后，系统会通过对后台数据库的访问查询改用户的权限是否符合当前操作，若不符合，则拒绝该操作，若符合，则将该文件内容呈现至系统中；用户在修改完文件内容后，可以对文件进行保存修改的操作，此时系统将再次查询后台数据库，对用户是否有这样的权限进行确认。

3.2框架结构

将公司资源模拟成相应的文件后，对每个角色的权限进行分配，如下表（由于表宽度无法将所有角色显示，因此只显示1产品生产线相应角色的权限，其中1产品生产线的角色无法访问任何2产品生产线中的任何资源）。如下表3-1所示：

表3-1

	入职须知	1产品简介	1产品财务报告	1产品生产报告	1产品销售报告	1产品质监报告	1产品核心技术	产品发展规划
基础员工	读
1产品员工	读	读
1产品财务员工	读	读	读、写	读	读	读
1产品质监员工	读	读	读	读	读	读、写
1产品生产员工	读	读	读	读、写	读	读
1产品销售员工	读	读	读	读	读、写	读
1产品经理	读	读、写	读、写	读、写	读、写	读、写	读、写
总经理	读、写	读、写	读、写	读、写	读、写	读、写	读、写	读、写

以上是用户在该系统中对文件资源的访问。

管理员在系统中可以实现对用户的创建，用户的角色的授予，角色的回收等操作。

创建用户是每个管理员都能使用的功能。

用户角色的授予则就要查询后台数据库中当前管理员是否有相应的权限这么做。授予权限表（Assign）如下表3-2所示：

表3-2

管理员角色	用户前提角色	可授予角色
公司主管	基础员工	总经理
公司主管	1产品经理	总经理
公司主管	2产品经理	总经理
高级主管	基础员工	[1产品员工，1产品经理]， [2产品员工，2产品经理]
高级主管	1产品财务员工	1产品经理
高级主管	1产品质监员工	1产品经理
高级主管	1产品生产员工	1产品经理
高级主管	1产品销售员工	1产品经理
高级主管	2产品财务员工	2产品经理
高级主管	2产品质监员工	2产品经理
高级主管	2产品销售员工	2产品经理
高级主管	2产品生产员工	2产品经理
高级主管	1产品员工	(1产品员工，1产品经理]
高级主管	2产品员工	(2产品员工，2产品经理]
1产品主管	基础员工	[1产品员工,1产品经理)
1产品主管	1产品员工	(1产品员工,1产品经理)
2产品主管	基础员工	[2产品员工,2产品经理)
2产品主管	2产品员工	(2产品员工,2产品经理)

上表中描述了授予角色表的管理员角色可以在用户符合某个前提角色的情况下可授予的角色。其中过多的数据以集合的开闭区间来表示。例如，一个用户的角色如果是基础员工，就可以被公司主管管理员授予总经理角色。

用户角色的回收也是需要验证管理员的身份，在回收之前，需要查询后台数据库中的数据，来确定是否可以对该用户的角色进行回收。如下表3-3所示：

表3-3

管理员角色	可回收角色
公司主管	[基础员工，总经理]
高级主管	[基础员工，总经理)
1产品主管	[基础员工，1产品经理]
2产品主管	[基础员工，2产品经理]

上表中描述的了回收角色表的管理员角色对应的可回收的角色的关系，与授予角色表不同的是回收角色不需要被回收的用户有任何前提条件。例如，一个公司主管可以回收从基础员工到总经理的用户的任何角色。

4. 数据结构

数据库中共存有五个表：user（用户）表，manager（管理员）表，role（角色）表，managerassign（授予角色）表，managerrevoke（回收角色）表。这五个表的数据结构设计如下：

User表：

列名	类型	长度	说明
username	Char	16	用户名
userpsd	Char	20	用户密码
role	Char	50	用户角色

Manager表

列名	类型	长度	说明
managername	Char	16	管理员名
managerpsd	Char	20	管理员密码
managerrole	Char	20	管理员角色

Role表

列名	类型	长度	说明
role	Char	20	用户角色
permissions	text	\	角色对应权限

Managerassign表

列名	类型	长度	说明
managerrole	Char	20	管理员角色
userrole	text	\	用户前提角色
assignrole	text	\	可授予角色

Managerrevoke表

列名	类型	长度	说明
managerrole	Char	20	管理员角色
revokerole	text	\	可回收权限

5. 接口设计

数据库的数据结构设计如上，相应的数据接口如下，我们使用java语言开发，设计了对应的四个类文件。

Manager类

public class Managers {

privateString managername;

privateString managerpsd;

privateString managerrole;}

User类

public class Users {

privateString username;

privateString userpsd;

privateString role;}

ManagerAssign类

public class ManagerAssign {

privateString managerrole;

privateString userrole;

privateString assignrole;}

ManagerRevoke类

public class ManagerRevoke {

privateString managerrole;

privateString revokerole;}

6. 模块介绍

6.1 主登录界面

主登录界面介绍，打开软件后，会有提示输入相应的用户名和密码的选项，填写完后选择登录的身份是普通用户还是管理员。界面如下图6-1所示：

图6-1

相应算法流程：当点击登录按钮后，根据选择的是普通用户还是管理员查询后台数据库中相应的表，若用户名与密码匹配则进入相应的界面，普通用户或者管理员界面。

普通用户功能

6.2 普通用户功能及算法流程

在登录后，会显示出当前用户名和当前用户的角色，在点击选择查看按钮后，会弹出一个选择文件的窗口，可以选择资源查看，如下图6-2所示：

图6-2

相应的算法流程：在选择相应的文件资源后，系统会查询数据库中该角色的所有权限，之后与用户所选择的文件进行对比，若含有该文件的权限，则将该文件的内容呈现到程序的空白框区域中，若没有则提示该用户没有读取该文件的权限，如下图6-3所示：

图6-3

用户对文件进行修改后，点击保存修改按钮时，系统再次查询数据库中的权限数据，该用户是否对该文件有写入的权限，若有，则保存当前数据至该文件，若没有，则提示无法保存，权限不够。

用户操作的整个流程图如下图6-4所示：

图6-4

6.3 管理员功能及算法流程

管理员登录后共有三个功能可以使用，创建用户，为用户增加角色，回收角色。

6.3.1 创建用户

创建用户这个功能不需要管理员的权限，只要是管理员就能行使创建用户的权利。界面如下图6-5所示：

图6-5

相应算法流程：在输入要创建的用户的用户名，密码，只能分配基础员工的角色。点击创建后，系统会首先查询数据库中是否已经有当前所输入的用户名，若已有，则创建失败，若没有，则成功创建。

该功能的流程图如下图6-6所示：

图6-6

6.3.2授予用户角色

授予用户角色功能需要先查询用户，再进行角色的授予。系统界面图如下图6-7所示：

图6-7

相应算法流程：在输入用户的用户名后，点击查找按钮查询数据库中的数据，若不存在该用户，系统会提示出错，若存在，则将该用户的角色显示出来，以及可授予的角色使用下拉菜单保存，管理员可选择相应的角色授予。

该功能实现的流程图如下图6-8所示：

图6-8

6.3.3 回收用户角色

回收角色功能同样需要查询相应的用户，在进行用户角色的回收。系统界面如下图6-9所示：

图6-9

相应算法流程：在管理员输入相应的用户名之后，点击查找即查询数据库中的用户数据，若不存在，则提示错误，若存在则显示用户角色以及对应该管理员的可删除的角色，可删除的角色使用下拉菜单显示出来，管理员选择相应的角色点击删除后，用户的角色即被删除。

该功能实现的流程图如下图6-10所示：

图6-10

6.3.4 数据库交互

因为在之前的开发中，数据库都需要dao，implementdao，service这三层架构，导致数据库的开发非常麻烦，我们使用了MyBatis工具，MyBatis是一个支持普通SQL查询，存储过程和高级映射的优秀持久层框架。MyBatis消除了几乎所有的JDBC代码和参数的手工设置以及对结果集的检索封装。我们只需要进行相关的配置就能完成对数据库的操作。

7. 开发和运行环境介绍

本系统是基于java语言开发的，使用mysql数据库作为系统后台的数据储存和交互的平台。开发环境是windows7操作系统下的myeclipse开发环境，使用jdk8。

本系统经过打包后的.jar包必须在以下前提的环境下运行：装有JVM（java虚拟机），mysql数据库，mysql数据库中有以上所提到的所有的表。

git仓库地址 https://github.com/ls7011846/AccessControl_RBAC

访问控制RBAC模型实现