实现基于角色的访问控制（RBAC）

Posted 2021-05-01 Authing认证云

Authorization at Authing

首先让我们用一句话区分认证（Authentication）和授权（Authorization）：

• 认证是识别请求方是谁的过程；

• 授权是知道了请求方是谁之后，判断其是否具备某些权限的过程；

Authing 支持非常丰富的认证、授权手段：

• 认证手段有：传统密码、验证码登录、丰富的第三方登录（微信、小程序、微博、GitHub、支付宝、QQ 等，未来还会有更多），以及企业级的 LDAP、SAML、OIDC 等。

• 授权手段有：完整的 OAuth、OIDC 流程。

对于授权流程，访问控制（Access Control）策略是非常重要的一环，目前 Authing 一共支持（或即将支持）三种访问控制手段：

• 老版本的用户角色（deprecated）

• RBAC

• ABAC（未来即将支持）

下面是 Authing  目前所支持或即将上线的相关 Feature：

• YES ：当前支持。

• In future release ：已加入未来规划，不久后将会支持。

• To be determined ：还在设计是否需要添加此功能。

Feature	Authing 支持情况	备注
角色
创建/修改/删除 角色	In future release
分页查询	YES
通过名称、描述搜索角色	YES
角色能被授予给分组	YES
角色嵌套、分层	In future release
角色通过 namespace、多租户管理	In future release
查询角色具备的所有权限	YES
查询角色中包含的所有用户	YES
用户
创建/修改/删除 用户	YES
分页查询	YES
通过昵称、邮箱搜索用户	YES
查看最近注册、登录的用户	YES
通过第三方应用查找用户	In future release
通过 lucence 语法搜索用户	In future release
用户可以拥有一个或多个角色	YES	最多 50 个
用户能在一个或多个分组里	YES	最多 50 个
查看一个用户具备的所有角色	YES
查看一个用户所在的所有分组	YES
查看一个用户所具备的所有权限	YES
通过 JSON 导入/导出用户	YES
自定义密码加密函数	YES
权限
创建/修改/删除 权限	YES
分页查询	YES
通过名称、描述搜索权限	In future release
能直接赋予用户权限	To be determined
能授权给一个或多个角色	YES
查询所有具有某个权限的用户	In future release
查询所有具有某个权限的角色	In future release
查询所有具有某个权限的分组	In future release
分组
分页查询	YES
创建/修改/删除 分组	YES
通过名称、描述搜索分组	In future release
直接从第三方用户目录导入（如 AD, LDAP, SAML）	In future release
分组嵌套、分层	In future release
查看分组的子分组	In future release
分组通过 namespace、多租户管理	In future release
查看一个分组具备的所有用户	YES
查看一个分组具备的所有角色	YES
查看一个分组具备的所有权限	YES
配置
自定义授权流程策略（authorization policies）	In future release
自定义是否将权限加入 Token	In future release	默认为否
自定义是否将角色加入 Token	In future release	默认为否
自定义是否将分组加入 Token	In future release	默认为否

什么是 RBAC

基于角色的访问控制（Role-based access control，简称 RBAC），指的是通过用户的角色（Role）赋予其相关权限，这实现了细粒度的访问控制，并提供了一个相比直接授予单个用户权限，更简单、可控的管理方式。

当使用 RBAC 时，通过分析系统用户的实际情况，基于共同的职责和需求，将他们分配给不同的角色。然后可以授予每个用户一个或多个角色，每个角色具有一个或多个权限，这种 用户-角色、角色-权限 间的关系，让我们可以不用再单独管理单个用户，用户从具备的角色里面继承所需的权限，从而使得用户赋权这件事变得更加简单。

举一个公司内所有在职员工具备登录公司邮箱的权限的场景，如果应用 RBAC，就可以赋予所有在职员工 employee 角色，employee 角色具备 email:login 权限，如此所有员工就具备了登录公司邮箱的权限。如果有员工离职，只需要将其移出 employee 角色，而不需单独收回权限。本质上，一个角色（Role）就是一组权限（Permission）的集合。使用角色添加、删除、调整权限，相比单独赋予单个用户权限更加简单。当你的用户基数不断增长时，角色会变得尤为有用。

在规划访问控制策略时，最佳实践是给予用户完成工作必须的最小权限。

‌

使用 RBAC 的优势

• 系统性、可重复性的权限指派

• 更方便的用户权限审计，快速定位问题

• 快速地添加、修改角色，甚至可以调用 API 实现

• 减少授予用户权限时发生错误的可能性

• 引入第三方用户/新用户/未登录用户时，赋予他们预先配置好的角色，比如 guest 分组

除了直接赋予用户某个角色，作为 RBAC 的最佳实践，我们还可以通过分组管理用户，将一个分组和一组角色绑定，在此分组内的所有用户就会继承这些角色，并自动具备了这些角色包含的权限。这些概念之间的关系为：Permission <-> Roles <-> Groups <-> Users， 如下图所示：

• 分组：Employee, Contractor

• 角色：Vacation Requester, Invoice Submitter, Express Submitter

• 权限：Read vacation requests, Create vacation requests 等

用分组管理用户、分组包含一组权限，这也是我们推荐使用的方式。

分组和角色的区别

分组(Group)和角色(Role)有什么区别？

• 角色是一组权限的集合。

• 分组侧重于管理用户，一个分组通常拥有多个角色，分组内的用户会继承分组内所有角色的所有权限。

常见的 Group 和 Role 示例：

• Group

• admin: 系统管理员，通常包含系统维护者。

• employee: 正式雇员。

• employer: 面试官。

• hr

• intern: 实习生

• ops_engineer: 运维工程师

• Role

• Invoice Submitter: 具备发票报销的相关权限。

• Vacation Requester: 具备申请假期的相关权限。

• Production Server Operator: 具备线上服务器的操作权限。

• HR App User: 具备使用 HR 系统的相关权限。

举例来说：可以这样建立 Role 和 Group 之间的关系：

• employee 拥有发票报销和申请假期角色，但是不具备线上服务器的操作权限。

• ops_engineer 拥有发票报销、申请假期、线上服务器的角色。

我们推荐使用分组管理用户，用 Role 管理权限，不要直接赋予单个用户某个权限。如果是某个用户临时需要具备某个角色，可以临时授予，结束之后再收回。

关于Authing

Authing 是面向开发者的身份云提供商，它为数千名客户提供了 Web，移动，IoT 和内部应用程序所需要的唯一身份解决方案。Authing 提供了高端可扩展的平台，每月验证数十万次登录，受到全球开发者和企业的喜爱和信任。