基于RBAC模型的权限管理系统

一，系统概述

基于RBAC模型的权限管理系统，不同的用户拥有不同的功能界面、不同的业务权限.从项目角度来描述就是不同的用户拥有不同的角色，不同的角色绑定了不同的功能模块，并且要保证用户不能操作权限之外的功能。基于这样的出发点可以考虑建立一套多用户、多角色、多种功能、用户<–>角色<–>菜单灵活绑定的系统。

‘基于角色的权限访问控制’（Role-Based Access Control），简称为RBAC。RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。

二，开发环境

Java版本：1.8
数据库：MySQL
框架：Spring + Spring MVC + MyBatis
服务器：Tomcat
前端框架：Easyui
开发工具：Eclipse
版本管理工具：Maven
版本控制工具：Svn

三，系统功能

系统结构图

功能要求

用户登陆分为：系统管理员登陆和普通用户登陆。

1. 系统管理员登陆为此权限系统

     2．普通用户登陆则显示此用户所有的权限菜单

提示：登陆使用员工号+密码验证，同时提供错误页面提示，和验证次数限制，提供登陆者信息保存。

菜单管理功能实现的是项目与菜单之间的对应关系，一个项目可以对应多个菜单，一个菜单也也以与多个项目相对应的多对多关系。

该模块实现的功能有：

    1．给项目分配新的菜单：给项目添加新的菜单，给项目增加新的功能。

    2．取消项目的某些菜单：取消项目的某些菜单，减少项目所具有的功能。

    3．修改项目的某些菜单：修改因某些原因导致的菜单与功能不匹配的问题。

    4．查询项目的菜单：查询该项目所具有的菜单项。

    5．判断项目是否启用：当项目停用时，该项目下的菜单不能使用。

角色管理模块就是对系统的角色进行管理：增加，停用，修改，查询。

    1．往本系统内增加角色。

    2．对已存在的角色进行查询操作。

    3．对已存在的角色进行修改操作。

    4．对已存在的角色进行停用操作。

系统登陆流程示意图

 

菜单管理流程示意图

角色管理流程示意图

角色菜单流程图

四，数据库表设计 

为了方便管理，每个程序对象都集中实现相关的一组管理功能，实现一个程序对象的数据管理功能。本系统所有的应用都是围绕数据库来进行的。在数据库中都有一组表存储管理的数据对象的数据。数据库设计与整个程序的实现有重要的关系。因此，需要制定统一的数据库设计规范，以配合程序设计，以及方便管理和维护。这是下面的数据库设计规则：

1. 表名的设计。数据库表名与程序名一致，一一对应，对于JAVA程序对象中的"."转换到数据库中就是"_"。假定有一程序，mis.mis1.class，则对应表名为mis_mis1，如果，还有子表，则以_a、_b等作为后缀扩展，如mis_mis1_a、mis_mis1_b等，对于流程相关的程序对象可以加_1、_2、_3等后缀，每个流程的子表可以以后缀表示为_1_a、_1_b表示；
2. PK的设计。每个表都有一个字段ID，类型为int，其由公共程序产生，与数据无关，仅仅标志一个独立的数据记录，ID字段为该表的PK。这里需要特别声明的是 PK 字段还有一个重要的作用，就是它的业务无关性，所有 PK 字段在业务程序实现过程中始终不需要在交互界面上表示出来，这样可以保证了数据的可维护性，也保证了系统的坚固性；
3. 子表的设计。根据数据字段属性的多少和功能，可以划分为若干子表，每个子表与主表通过ID字段建立关联，统一构成一条独立的数据记录，如果主表与子表为一对多关系，则在子表中增加一个字段SEQ，在子表中ID+SEQ字段构成子表的PK，子表中的ID字段通过FK关联主表的ID字段；
4. UK的设计。根据业务功能需要，对主表或者子表中的业务相关字段，设计UK，通过设计UK严格实现业务应用中唯一性的要求，UK也是将来规划查询实现的线索字段；
5. FK的设计。外键设计可以用外键字段关联的目的表的表名后加_id后缀实现。这样，可以从数据库表结构中一目了然地了解数据之间的关联，这样也符合面向对象的思维习惯，比如某个表中有字段mis1_id，表示该字段外键关联到mis1表的ID字段，只要将字符“_”读为“的”就行，这里“_”相对于面向对象中常见的符号“.”。
6. NULL属性的设计。对于业务上必须要求填写的内容，对应的字段为NOT NULL,对于可以不必填写的字段，设置为NULL。
7. 设计文档格式－“表名 | 主/外键 | 字段 | 类型 | NULL? | 字段说明”,表名和字段名采用英文单词，可以适当采用缩写。
8. 表名和字段名称采用英文单词书写，建议采用小写字母。如果字段由多个单词组合，则第一个单词大写，后面单词的第一个字母小写。
9. 系统核心表以下划线“_”为前缀，其他应用表名的各个单词第一个字母可以大写开始

上面的关于表的设计规则也是与程序设计相配合的，因为这样设计，只要知道程序的名字，如mis.mis1.class就知道其管理的数据在以“mis_mis1”开头的一系列表中，就能将程序和数据很快定位，而每个独一无二的ID表示一个记录，程序就是管理这个数据对象集合（collection）的。这样也是大大方便程序开发、管理、维护的。当然，在实际开发中，对于特殊的系统管理程序，也可以根据设计需要灵活设计数据库结构，但是，建议业务性质的数据表设计最好采用上述规则，这是对整个系统是有益的。

E-R图

user:用户表用于存放用户基础数据

role：角色表用户存放角色名称

user-role：用户角色表，存放用户表id河角色表id，一个用户id可能会对应多个角色id，如果使用数据量很大，建议对两个id字段做索引

menu：菜单表用户存放所有功能菜单，包含菜单名称、链接、标签、父级id、菜单等级等数据，因为菜单数据要在权限设定时做展示，所以数据要设计为输结构，方便加载和筛选

role-menu：角色菜单表用户存放角色id和菜单id的关联关系，同样一个角色id可能会对应多个菜单id，数据量大的情况下建议对两个id字段做索引

五，系统展示

六，总结

      本文论述了一种基于RBAC的权限管理系统的实现技术方案。该权限管理系统已成功应用于教师测评系统的设计和开发实践，与教师测评系统具有很好的集成。实践表明，采用基于RBAC模型的权限管理系统具有以下优势：由于角色／权限之间的变化比角色／用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销；而且能够灵活地支持应用系统的安全策略，并对应用系统的变化有很大的伸缩性；在操作上，权限分配直观、容易理解，便于使用；分级权限适合分层的用户级形式；重用性强。