- A+
权限术语
-
Subject：用户，用户组
-
Action：对Object的操作，如增删改查等
-
Object：权限作用的对象，也可以理解为资源
-
Effect：规则的作用，如允许，拒绝
-
Condition：生效条件
-
Permission：允许（拒绝）用户（用户组）在条件允许下对对象（资源）的动作
-
Role：权限集合，权限数量>=1
RBAC
RBAC (Role-Based Access Control，基于角色的访问控制)，引入了 Role（角色）的概念，并且将权限与角色进行关联。用户通过扮演某种角色，具有该角色的所有权限。
即权限，角色，用户之间的关系是多对多对多
RBAC0
- 用户
- 角色
- 权限
- 会话
用户和角色的关系是多对多
权限和角色的关系是多对多
RBAC1
- 角色继承
- 权限扩展
RBAC2
-
互斥约束
用户，角色，权限均可互斥。不允许存在任意冲突。
-
基数约束
角色分配次数受限，比如一个公司只有一个CEO
-
先决条件角色
权限赋予要从低到高。如：要先有XX副总权限才能获取XX总权限。
-
静态职责分离（目前先支持静态职责分离）
用户无法被赋予冲突的角色
-
动态职责分离
用户会话中无法激活冲突的角色
RBAC3
RBAC0 + RBAC1 + RBAC2
ABAC
Attribute Based Access Control，基于属性的权限验证。允许更细粒度的控制X属性的Y资源在Z条件下进行A操作。相较于RBAC，会对开发人员提出更高的要求，目前我们先只介绍到RBAC。
举个例子
我们通过预设博客文章场景来反推实现方式
用户角色
一篇文章要面对两种角色，即：读者，管理员
[{ "Subject": "Avril", "Roles":["ArticleReader"] }, { "Subject": "Dodd", "Roles":["ArticleManager"] }] 角色
读者将获得读文章权限，管理员则获得管理文章权限
[ { "Name": "ArticleReader", "Permissions": [ "ReadArticle" ] }, { "Name": "ArticleManager", "Permissions": [ "ManageArticle" ] } ] 权限
角色有了，依赖的权限也有了，接下来我们需要继续把权限明细确认一下
[ { "Name": "ReadArticle", "Effect": "Allow", "Action": ["Read"], "Object": ["Article"] }, { "Name": "ManageArticle", "Effect": "Allow", "Action": ["Create", "Read", "Update", "Delete"], "Object": ["Article"] } ] 依赖模型
基于RBAC3的依赖模型
用户管理
简单的引入一个RBAC无法满足一个工程化的项目，比如批量操作，前后端集成等
团队
单个用户的管理已经出来了，但日常中我们很少会对单个用户进行授权。更多的是针对一组（批）人进行操作。
前端集成
到目前为止，我们设计的都还在后端。而前端关心的是页面展示相关的，比如菜单，页面元素等
等一下！
这里要设计什么？或许可以偷个懒，在Objects里增加一个ObjectType用来区分菜单还是页面元素即可？
ObjectType被修改的可能性很小，所以我们将在SDK中提供枚举来支持
总结
至此，我们把RBAC与用户管理的部分已经设计完了。或许它缺少了传统意义上的组织架构树，但它带来了更加松散的，扁平化的团队管理。
（本文章不代表最终设计）
开源地址
MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks
MASA.Contrib：https://github.com/masastack/MASA.Contrib
MASA.Utils：https://github.com/masastack/MASA.Utils
MASA.EShop：https://github.com/masalabs/MASA.EShop
MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor
如果你对我们的 MASA Framework 感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们
