MASA Auth - 权限设计

权限术语

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"]
    }
]