权限管理架构

NET 通用高扩展性的细粒度权限管理架构(webApi/Mvc)

一. 权限场景分析:

 

1. 系统具有角色概念, 部门概念, 且都具有相应不同的权限

 

2. 用户具有多个角色, 多个部门等关系, 并且能给单个用户指派独有的权限

 

3. 具有细粒度权限控制到资源的RBAC, 能控制页面, 控制菜单, 控制逻辑, 控制单个操作, 控制到单一数据; 且具有一定的可扩展性

 

4. 适用于webapi/ mvc / wcf / webservice  混合项目中

 

5. 设置权限和验证权限易用性高

 

 

 

 

 

二. 数据库表设计

 

　　1. 角色表

 

　　2. 部门表

 

　　3. 用户表

 

　　4. 菜单表

 

　　5. 用户表

 

　　6. 权限表

 

　　7. 用户角色关系表

 

　　8. 用户部门关系表

 

　　9. 菜单权限关系表

 

　　10.用户权限关系表

 

　　11.部门权限关系表

 

　　12. 权限汇总表

 

在一般正常的情况下, 大家伙都会有 菜单权限关系, 用户权限关系, 部门权限关系等表, 在此处省去如上几项权限关系表,  将如上权限表做成dll 当插件形式容入到项目中.

 

权限汇总表描述:

 

　　既然将如上所有跟权限有关联的关系表剔除后该如何来设计各种来自不同体系的权限呢? 因此在此权限汇总表中要有字段来定位到, 该条权限是属于什么体系.

 

　　因此权限汇总表中出现三个至关重要的字段: 

 

　　　　1. PermissionType(权限的类型: 菜单,部门,角色,用户 ); 

 

　　　　2. PermissionReferenceId(权限类型的引用ID: 当Type为角色时 为角色的ID 以此类推); 

 

　　　　3. PermissionAction(权限操作的ID: 每个权限将会划分为一个操作编号ID, 往后会深入讲解)

 

 

 

 

 

 

 

 

 

三. 权限无处不在

 

若要让设置权限和验证权限易用性高, 最好的解决方案则是利用 Attribute 来进行权限的设置.

 

如图：

 

 

 

 

 

 

 

 

将PermissionKinds 划分为 菜单 和 数据

 

 

 

PermissionActions 则是 标识操作资源的权限编号

 

例:  用户表: User_Read = 10, User_Edit=11, User_Add=12, User_Delete=13  (当然此处也可以进行扩展如: 搜索用户 User_Search=14)

 

 

 

 至此,我们只需要要将要 进行权限审核验证的方法上进行 permissionattribute 标记即可

 

附上相应的codesmith 代码生成

 

 

 

 

 

 

 

四. 权限认证

 

1. 在用户登录时,将用户所在的所有角色组权限, 和部门权限全部查询出来合并,并添加到缓存中.

 

2. 当用户在访问指定的资源或action方法前 进行验证其是否具有相应权限

 

 

 

实施方案:

 

1.webapi

 

　　新建 Filter 实现 IAuthorizationFilter 接口　　

 

 

 

2. mvc

 

　　新建Filter 实现 IAuthorizationFilter 接口