ABP module-zero +AdminLTE+Bootstrap Table+jQuery权限管理系统第十三节--RBAC模式及ABP权限管理（附赠福利）

最新推荐文章于 2025-10-29 08:02:55 发布

原创

最新推荐文章于 2025-10-29 08:02:55 发布 · 2.8k 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#bootstrap #ABP #RBAC #github

ABP+AdminLTE+Bootstrap Table权限管理系统一期
 Github:https://github.com/Jimmey-Jiang/ABP-ASP.NET-Boilerplate-Project-CMS

角色访问控制RBAC
RBAC结构
ABP权限管理

角色访问控制（RBAC）

角色访问控制（RBAC）应该是目前用得最多也是关注最多的权限管理模型了。
权限（Permission）与角色（Role）相关联，用户（User）通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。
RBAC引入了角色（Role）概念，目的应该是解耦了Permission与User之间的关系，直接授权给Role，而不是直接授权给用户，或者用户组。
基于角色的访问控制方法（RBAC）的显著的两大特征是：
1. 由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理开销。
2. 灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
RBAC支持三个著名的安全原则：最小权限原则，责任分离原则和数据抽象原则。
（1）最小权限原则之所以被RBAC所支持，是因为RBAC可以将其角色配置成其完成任务所需要的最小的权限集。
（2）责任分离原则可以通过调用相互独立互斥的角色来共同完成敏感的任务而体现，比如要求一个计帐员和财务管理员共参与同一过帐。
（3）数据抽象可以通过权限的抽象来体现，如财务操作用借款、存款等抽象权限，而不用操作系统提供的典型的读、写、执行权限。然而这些原则必须通过RBAC各部件的详细配置才能得以体现。

RBAC结构

RBAC认为权限授权实际上是Who、What、How的问题。在RBAC模型中，who、what、how构成了访问权限三元组,也就是“Who对What(Which)进行How的操作”。

Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）,
- What：权限针对的对象或资源（Resource、Class）。
- How：具体的权限（Privilege,正向授权与负向授权）。
- Operator：操作。表明对What的How操作。也就是Privilege+Resource
- Role：角色，一定数量的权限的集合。权限分配的单位与载体,目的是隔离User与Privilege的逻辑关系.
- Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户而给组。组可以包括组(以实现权限的继承)，也可以包含用户，组内用户继承组的权限。User与Group是多对多的关系。Group可以层次化，以满足不同层级权限控制的要求。
  1. RBAC的关注点在于Role和User, Permission的关系。称为User assignment(UA)和Permission assignment(PA).关系的左右两边都是Many-to-Many关系。就是user可以有多个role，role可以包括多个user。
  2. 凡是用过RDBMS都知道，n:m 的关系需要一个中间表来保存两个表的关系。这UA和PA就相当于中间表。事实上，整个RBAC都是基于关系模型。
  3. Session在RBAC中是比较隐晦的一个元素。标准上说：每个Session是一个映射，一个用户到多个role的映射。当一个用户激活他所有角色的一个子集的时候，建立一个session。每个Session和单个的user关联，并且每个User可以关联到一或多个Session.
  4. 在RBAC系统中，User实际上是在扮演角色(Role)，可以用Actor来取代User，这个想法来自于Business Modeling With UML一书Actor-Role模式。考虑到多人可以有相同权限，RBAC引入了Group的概念。Group同样也看作是Actor。而User的概念就具象到一个人。
    这里的Group和GBAC（Group-Based Access Control）中的
  5. Group（组）不同。GBAC多用于操作系统中。其中的Group直接和权限相关联，实际上RBAC也借鉴了一些GBAC的概念。
  6. Group和User都和组织机构有关，但不是组织机构。二者在概念上是不同的。组织机构是物理存在的公司结构的抽象模型，包括部门，人，职位等等，而权限模型是对抽象概念描述。组织结构一般用Martin fowler的Party或责任模式来建模。
  7. Party模式中的Person和User的关系，是每个Person可以对应到一个User，但可能不是所有的User都有对应的Person。Party中的部门Department或组织Organization，都可以对应到Group。反之Group未必对应一个实际的机构。例如，可以有副经理这个Group，这是多人有相同职责。
  8. 引入Group这个概念，除了用来解决多人相同角色问题外，还用以解决组织机构的另一种授权问题：例如，A部门的新闻我希望所有的A部门的人都能看。有了这样一个A部门对应的Group，就可直接授权给这个Group。

ABP权限管理

首先ABP权限管理也是基于RBAC的。
在 RBAC之中,包含用户users(USERS)、角色roles(ROLES)、目标objects(OBS)、操作operations(OPS)、许可权permissions(PRMS)五个基本数据元素，权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。会话sessions是用户与激活的角色集合之间的映射。
然后我们来看一下一开始就生成的AbpPermissions表。

我们可以看到一个权限（AbpPermissions）有以下属性：
Name：系统范围内的唯一名字。把它定义为一个字符串常量是个不错的注意。我们倾向于将“.”分割不同的层级，但并不要求这么做。你可以设置你任何喜欢的名字。唯一的规则就是这个名字必须是唯一的。

- Display Name：使用一个本地化的字符串去显示权限到UI。

Description：和Display Name类似。
IsGrantedByDefault：此权限是否授权给（已登陆）所有用户，除非显示指定。通常设置为False（默认值）。
MultiTenancySides：对租户应用程序，一个权限可以基于租户或者主机(原文:host)。这是个枚举标识，因此权限可以应用于不同方面。一个权限可以有父权限和子权限。