结合前台UI和后台业务的统一的权限控制模型

最近被分配设计一个基于RBAC的权限模型,但是需要最好能将前台UI作为权限元素一起管控起来,遂写了个方案大家仍鸡蛋.

一．概述：
此设计方案书为电脑中心软件科提供统一的应用系统权限管理的功能设计，以此建立通用的权限管理平台。此设计为基于角色的访问控制权限（RBAC：Role Based Access Control）模型，并在此基础上作了相应扩展使其在各应用系统之间（主要针对web应用）具备通用性和兼容性。

二．源代码组织结构：
项次 包名 包描述 类名
1 com.kop.ac 顶级包 　
2 com.kop.ac.core 核心包 Role
3 User
4 Permission
5 Group
6 com.kop.ac.extend 扩展包 Page
7 Action
8 ModelObject
9 Method
10 Dao


三．设计思路：
3.1 基于角色的核心权限模型
根据RBAC规范，以角色为核心构建的权限模型如下图所示：

具体类说明如下：
com.kop.ac.core.Permission
代表权限系统中的权限资源要素，为所有实际权限要素的父类。

com.kop.ac.core.Role
角色即权限的集合，用以连接User和Permission，降低用户和权限之间的耦合度。某一角色可以同时具有一个或多个权限，某一权限也能被分配给一个或多个角色。另外，权限系统也支持角色的继承。

com.kop.ac.core.User
用户可同时跟一个或多个角色关联，也可和一个或多个单独的权限元素关联（但不推荐使用）。

com.kop.ac.core.Group
组即权限要素和角色的集合，可与零到多个用户相关联。组概念的提出是为了解决大量具有相同权限的用户授权问题，提高工作效率。


3.2 针对Web应用的扩展模型
如下图所示为权限系统中对实际Web应用中各权限资源要素的分层结构：

com.kop.ac.extend.Page
代表web应用中页面抽象概念的对象，是表现层权限控制的要素之一。处于权限要素树中的最上一层。用以控制用户是否具有访问某一页面的权限，其权限值为其包含的所有Action权限的或运算。

com.kop.ac.extend.Action
代表web应用中业务动作抽象概念的对象，是表现层权限控制要素之一，表示用户在页面上能进行的业务操作。它处于权限要素树中的第二层，一个或多个Action组合（而非简单聚合）为一个Page。Action由一个或多个Method聚合而成，并处于同一个事务范围中。此权限要素针对的为一般用户。

com.kop.ac.extend.ModelObject
代表web应用中领域模型对象概念的对象，是实际执行Action的主体，为业务层中模块级别的权限控制要素。通常用以在模块级别上进行宏观权限设定，以此来过滤不符合设定条件的权限控制要素。ModelObjct由一个或多个Method组合而成。此权限要素只针对系统级角色（包括系统管理员和第三方系统调用）开放。

com.kop.ac.extend.Method
代表web应用中领域对象行为概念的对象。是组成业务操作的具体执行单元，处于权限要素树的第三层。为细粒度权限要素，只针对第三方系统调用开放。由一个或多个Dao组合而成。

com.kop.ac.extend.Dao
代表web应用中领域对象持久性操作概念的对象，为权限系统中最细粒度的权限划分单位，处于权限要素树的最底层。用以根据模块权限设定，计算权限要素树中上层各要素的权限值。

五．工作方式：
5.1 权限资源初始化
所有继承自Permission类且位于com.kop.ac.extend包下的对象将作为权限系统的可用权限资源要素组成一颗权限资源树（Resource Tree）。在web应用发布上线之前，由权限模块中的ResourceManagerd类对web应用源代码进行解析，找出web应用中实际存在的页面、业务操作、领域对象以及对象的方法和持久操作方法，将他们映射为权限模块中的权限资源要素并以树的形式保存于数据库或者缓存中。这一过程称为权限资源的初始化过程。

5.2 权限配置
5.2.1前台权限配置
前台可对权限系统的Action进行配置，web应用的系统管理员可以通过配置页面建立Action和Role、Action和User以及Action和Group之间的关联。另外，系统管理员也可以针对模块级别ModelObject的设定权限（比如只读，或者禁止写）。

5.2.2 后台权限配置
针对后台第三方系统调用由应用开发人员或者应用需求人员指定Method级别的权限管控，建立用户跟Method之间的关联进行授权和验证。

5.3 应用生效
当一个请求（Request）到达后，会被实现了ServletFilter接口的AcManager权限引擎截获，提取出请求对应的URL和当前用户信息，然后通过在权限资源树（持久化的或者缓存中）查找进行权限验证。具体的验证算法以及权限资源树的组织请参见下一节内容。


八．问题点：
1. 编写代码自动初始化权限资源树在技术方面可行性不高；
2. 进行Page管控的技术问题：以URL作为Page的主键产生的问题，redirect和forward问题；

兄弟可以把图发上来么    这样看不是很直观

恩 图已经补上了 其实就是多RBAC level 1的模型作了一点小小的扩展
而且我在想是不是没有必要多这么些资源权限要素的类,只用一个枚举说明资源类型就可以了

昨天晚上重新想了一下，发现这样的模型可扩展性基本上为零
每次新增一个页面或者一个Action都会需要重新配置权限mapping 还是需要根据经典的RBAC中的Resource+Operation的方法来定义Permission