最早的模型

最早最基础的权限管理模型是ACL，也就是Access Control List(访问控制列表)。
它是用来描述用户和权限之间关系的数据列表。它的原理非常简单：每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行CRUD等操作。当试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。
ACL几乎不需要任何基础设施就可以完成访问控制，这是他的简单性，也是他的优点。
但由于需要维护大量的访问权限列表，ACL在性能上有明显的缺陷。另外，对于拥有大量用户与众多资源的应用，管理访问控制列表本身就变成非常繁重的工作。

最开始的ACL定义中，用户直接和权限挂钩，数据存储的是用户与权限的关联关系。如果两个用户的权限是一样的，那么就需要分别存储这两个用户与权限的关联关系，也是上面所提到的ACL的缺陷。为了解决这些问题，便有了对ACL设计的改进，相同权限的用户放到同一个分组里，分组与权限挂钩，不再是用户直接与权限挂钩。以及后来出现的RBAC(基于角色的访问控制)，角色与分组也是差不多的概念，角色直接与权限挂钩，用户再与角色进行关联。

RBAC(Role-Based Access Control 基于角色的访问控制)

ACL的访问控制机制中，直接维护的是用户与功能的关系，这一系列的关系就是一个权限列表。当很多的用户具有相同功能权限的时候，就要进行繁琐的关联操作。RBAC就是在用户与权限之间引入了角色的概念。用户与角色之间做关联，权限列表维护的是角色与功能的关系。

一个用户拥有若干个角色，每个角色拥有若干个权限，这样就构成了“用户-角色-权限”的授权模型。这种授权模型的好处在于，不必每次创建用户时都进行权限分配的操作，只要分配用户相应的角色即可，而且角色的权限变更比用户的权限变更要少得多，减少频繁设置。

在RBAC模型中，“用户-角色-权限”之间形成的关系是一个双向的”一对多“的关系。
也就是说，一个用户可以拥有多个角色，一个角色可以赋给不同的用户；一个角色可以拥有多个权限，一个权限也可以被多个角色拥有。

角色的引入，可以让具有相同权限汇集到一起，再将不同角色分配给不同的用户，以此来实现用户对于权限的分配。这样只需要在首次给不同的角色配上相应的权限，后续添加的用户就可直接赋予角色，便可添加上所需要的权限如此一来大大减少了操作的频繁性。

在后续的发展中，我们发现单单在用户和权限中引入角色，对于大数据量的角色和权限的分配，还是具有相当的复杂度。如果一个部门上万人，那么我们就需要给这个部门上万人分别设置角色，而这上万其实是具有相同的权限的，如果直接采用基础的RBAC权限模型的话，那么面对这样的情况，无疑也是具有一个庞大的重复的工作量，并且也不利于后期用户变更的维护管理。

于是我们可以再在用户与角色之间引入”部门“的概念。
所谓”部门“就是将具有相同角色的用户进行分类，从而形成用户组的概念。
如此一来，我们将具有相同角色的用户归到一起，形成一个用户组，也就是一个”部门“，由此进行批量的调度和权限的管理，可以大大提高分类的清晰程度和我们工作的效率。

给具有相同权限的用户建立用户组，将用户组关联到对应的角色下，此用户组就拥有了此角色下的所有权限，而用户是属于用户组的，所以用户组下的所有用户也就同样的拥有了此角色下的所有权限。一个用户可以属于多个用户组，一个用户组也可以包括多个用户，所以用户与用户组是多对多的关系。

RBAC级别

RBAC0 用户和角色是多对多，角色和权限是多对多。一个用户拥有的权限，是他所有角色的集合。
RBAC1。基于RBAC0，并引入了角色分层的概念，即一个角色分为多个等级，每个等级对应的权限是不一样的。把权限分给用户时，需要分到对应的角色等级。角色等级低时拥有的权限少，角色等级高的权限是所有角色等级低的权限的集合。

RBAC2 基于RBAC1，对角色访问进行限制。如
互斥角色限制。同一个用户分配到两个角色，且角色互斥时，那么系统应该提醒只能选择其中一个角色。比如员工拥有商务这个角色，可以创建结算单并提交给财务审核，这时，就不能赋予这个员工财务角色，否则他就自己提交结算自己审核结算单了。
角色数量限制。一个用户拥有的角色数量是有限的；一个角色被分配的用户数量也是有限的。
先决条件限制。用户想获得某个上级角色，必须先获得其下一级的角色。比如想获得产品总监的权限，那就需要从产品助理这一角色开始，再到产品经理角色，最后到产品总监角色。

RBAC3 基于RBAC0，对RBAC1和RBAC2进行了整合，是最全面的权限管理。用户组
当平台用户的基数增大，角色类型越来越多时，而且一部分人具有相同的属性，比如财务部的所有员工。

ABAC(Attribute-Based Access Control 基于属性的权限验证)

ABAC被称为是权限系统设计的未来。

在结构化语言中使用属性作为构建基石来定义并实施访问控制，提供上下文相关的细粒度动态访问控制服务。ABAC是一种为解决行业分布式应用可信关系访问控制模型，也表示词语的一种构成形式。

ABAC是一种为解决行业分布式应用可信关系访问控制模型，它利用相关实体(如主体、客体、环境)的属性作为授权的基础来研究如何进行访问控制。基于角色的访问控制（RBAC）通过引入角色中间元素，使得权限先经过角色进行聚合，然后再将权限分配给主体，通过这种方式可以简化授权，可将角色信息看成是一种属性，这样 RBAC 就成为了ABAC 的一种单属性特例。

在ABAC中，主体是对客体(资源)实施访问行为的实体，如用户、服务、通信实体等;

主体有定义其身份和特性的属性，包括主体的身份、角色、职位、能力、位置、行政关系以及CA
证书等，如用户这一主体，它可以以所处行业中用户属性特征为基础，将这些用户的某些属性进行标准化定义，包括某用户所属的部门、职务、主管业务等;

客体是被主体操作的实体，如文件、数据、服务、系统设备等，客体属性包括身份、位置(URL)
、大小、值，这些属性可从客体的“元数据”中获取，同样也可以由对其操的主体来继承。这就是说，客体属性与主体属性具有一定的相关性;
环境属性是与事务(或业务)处理关联的属性,它通常与身份无关,但适用于授权决策，如时间、日期、系统状态、安全级别等。

ABAC授权模型理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。从使用场景来说比较适用于用户数量多并且授权比较复杂的场景。

举个例子：

P5（职级）的研发（职位）同学在公司内网（环境）可以查看和下载（操作）代码

这个例子中的”职级“”职位“”环境“”操作“，就是实体的属性、操作类型、相关的环境，根据这四点来判断，此时该用户是否有某些权限。
比如同样是在内网，这个开发同学有权限操作代码，而运营同学没有这个权限；或者同样是这个开发同学，他在内网有操作代码的权限，而在公司外没有这个权限。

通俗的讲，就是对用户实体的实体属性（比如工号，职级，职位等）、环境属性（IP、时间、地点等）、操作树形（增加、删除、修改、查看等），来计算出当前用户是否有权限。

如何选择

在这里，组织的规模是至关重要的因素。由于ABAC最初的设计和实施的困难，对于小型企业而言，可能太过复杂了。

对于中小型企业，RBAC是ABAC的简单替代方案。每个用户都有自己的角色，并具有相应的权限和限制。当用户转移到新角色时，其权限将更改为新职位的权限。这意味着，在明确定义角色的层次结构中，可以轻松管理少量的内部和外部用户。

但是，当必须手动建立新角色时，对于大型组织而言，效率并不高。一旦定义了属性和规则，当用户和利益相关者众多时，ABAC的策略就更容易应用，同时还降低了安全风险。

简而言之，如果满足以下条件，就选择ABAC：

你在一个拥有众多用户的大型组织中；

你需要深入的特定访问控制功能；

你有时间投资远距离的模型；

你需要确保隐私和安全；

但是，如果满足以下条件，请考虑RBAC：

你所在的是中小型企业；

你的访问控制策略广泛；

你的外部用户很少，并且你的组织角色得到了明确定义；

参考文章：

https://baike.baidu.com/item/abac/3555041?fr=aladdin
https://blog.csdn.net/qq_31960623/article/details/120528589
https://blog.csdn.net/zl1zl2zl3/article/details/82968140?spm=1001.2101.3001.6650.1&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-82968140-blog-120528589.pc_relevant_default&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1-82968140-blog-120528589.pc_relevant_default&utm_relevant_index=2
https://blog.csdn.net/hi_bigbai/article/details/120868485?spm=1001.2101.3001.6650.2&utm_medium=distribute.pc_relevant.none-task-blog-2_defaultCTRLIST_{default-2-120868485-blog-82968140.pc_relevant_aa&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2}default_CTRLISTdefault-2-120868485-blog-82968140.pc_relevant_aa
https://www.jianshu.com/p/32e548fbba35
https://blog.csdn.net/qzw752890913/article/details/124461952
https://blog.csdn.net/qq_46311811/article/details/122444864?spm=1001.2101.3001.6650.6&utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-6-122444864-blog-124461952.pc_relevant_default&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-6-122444864-blog-124461952.pc_relevant_default&utm_relevant_index=9
https://juejin.cn/post/6844904056876433416#heading-12

权限管理中的RBAC与ABAC相关推荐

数据权限设计：从RBAC到ABAC的演变
本文来说下数据权限设计之从RBAC到ABAC的演变文章目录概述数据权限的发展历史从RBAC到ABAC 本文小结概述名词解释 ACL:Access Control List RBAC:Rol ...
【概念】权限管理模型（RBAC、ABAC、ACL）
目录 1.RABC模型 2. ABAC 模型 3. ACL模型 4. 总结在管理系统中会涉及到很多用户权限相关问题,对于不同的平台所使用的的权限管理模型也是多样的. 1.RABC模型该模型是基于角 ...
权限系统设计模型分析（DAC，MAC，RBAC，ABAC）
此篇文章主要尝试将世面上现有的一些权限系统设计做一下简单的总结分析,个人水平有限,如有错误请不吝指出. 术语这里对后面会用到的词汇做一个说明,老司机请直接翻到常见设计模式. 用户发起操作的主体. ...
权限管理模型 ---- ACL、RBAC和ABAC(详解)
前言在管理系统中会涉及到很多用户权限相关问题,对于不同的平台所使用的的权限管理模型也是多样的. ACL 基于用户的权限管理模型基于用户的概念就是说直接对用户进行权限分配管理,好处是模型构建简单,只 ...
Kubernetes权限管理与控制-RBAC
Kubernetes权限管理与控制-RBAC 1.Kubernetes api访问控制用户通过kubectl.客户端库或者通过发送REST请求访问API.用户和Kubernetes服务账户都可以被授 ...
复杂场景下的权限系统该怎么玩？ABAC权限模型帮你搞定它！
ABAC授权模型常用的授权模型 ABAC的访问控制表达式语言 SpEL性能 ABAC实践 crud代码 security上下文数据库设计 java程序测试类 Spring Security 和 ...
PHP -Casbin: 支持 ACL、RBAC、ABAC 多种模型的 PHP 权限管理框架
PHP-Casbin 是一个用 PHP 语言打造的轻量级开源访问控制框架( https://github.com/php-casbin/php-casbin ),目前在 GitHub 开源.PHP-C ...
权限模型 DAC ACL RBAC ABAC
访问控制方式访问控制介绍自主访问控制(DAC,Discretionary Access Control) 强制访问控制 (MAC,Mandatory Access Control) 访问控制列表 ...
rbac java框架_jCasbin：支持MAC、RBAC、ABAC多种模型的Java权限管理框架
jCasbin是一个用Java语言打造的轻量级开源访问控制框架(https://github.com/casbin/jca...),目前在GitHub开源.jCasbin采用了元模型的设计思想,支持多 ...

权限管理中的RBAC与ABAC