你的位置:首页 > 软件开发 > ASP.net > ASP.NET 系列:RBAC权限设计

ASP.NET 系列:RBAC权限设计

发布时间:2016-01-30 09:00:07
权限系统的组成通常包括RBAC模型、权限验证、权限管理以及界面访问控制。现有的一些权限系统分析通常存在以下问题:(1)没有权限的设计思路认为所有系统都可以使用一套基于Table设计的权限系统。事实上设计权限系统的重点是判断角色的稳定性和找出最小授权需求。角色的稳定性决定了系统是通 ...

权限系统的组成通常包括RBAC模型、权限验证、权限管理以及界面访问控制。现有的一些权限系统分析通常存在以下问题:

(1)没有权限的设计思路

认为所有系统都可以使用一套基于Table设计的权限系统。事实上设计权限系统的重点是判断角色的稳定性和找出最小授权需求。角色的稳定性决定了系统是通过角色判断权限还是需要引入RBAC方式,最小授权需求防止我们过度设计导致超出授权需求的权限粒度。

(2)没有独立的RBAC模型的概念

直接使用实体类表示RBAC模型,导致本身本应该只有几行代码且可以在项目级别复用的RBAC模型不仅不能复用,还要在每个项目无论是否需要都要有User、Role、Permission等实体类,更有甚者把实体类对应的数据表的结构和关联当作权限系统的核心。

(3)权限的抽象错误

我们通常既不实现操作系统也不实现数据库,虽然操作系统的权限和数据库的权限可以借鉴,但一般的业务系统上来就弄出一堆增删该查、访问和执行这样的权限,真是跑偏的太远了。首先业务层次的操作至少要从业务的含义出发,叫浏览、编辑、审核等这些客户容易理解或就是客户使用的词汇更有意义,更重要的是我们是从角色中按照最小授权需求抽象出来的权限,怎么什么都没做就有了一堆权限呢。

(4)将界面控制和权限耦合到一起

开始的时候我们只有实体类Entities、应用服务Service以及对一些采用接口隔离原则定义的接口Interfaces,通常这个时候我们在Service的一个或多个方**对应1个权限,这个时候根本界面还没有,就算有界面,也是界面对权限的单向依赖,对于一个系统,可能不止有1个以上类型的客户端,每个客户端的界面访问控制对权限的依赖都应该存储到客户端,况且不同的客户端对这些数据各奔没有办法复用。

 下面我们使用尽可能少的代码来构建一个可复用的既不依赖数据访问层也不依赖界面的RBAC模型,在此基础上对角色的稳定性和权限的抽象做一个总结。

1.创建RBAC模型

使用POCO创建基于RBAC0级别的可复用的User、Role和Permissin模型。

using System.Collections.Generic;namespace RBACExample.RBAC{  public class RBACUser  {    public get='_blank'>string UserName { get; set; }    public ICollection<RBACRole> Roles { get; set; } = new List<RBACRole>();  }  public class RBACRole  {    public string RoleName { get; set; }    public ICollection<RBACPermission> Permissions { get; set; } = new List<RBACPermission>();  }  public class RBACPermission  {    public string PermissionName { get; set; }  }}

原标题:ASP.NET 系列:RBAC权限设计

关键词:ASP.NET

*特别声明:以上内容来自于网络收集,著作权属原作者所有,如有侵权,请联系我们: admin#shaoqun.com (#换成@)。