RBAC | 使用authing实现基于角色的访问控制

一、认证 vs 授权？

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

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

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

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

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

• 老版本的用户角色（deprecated）
• RBAC（基于角色的访问控制，2020/02/03 已经上线）
• ABAC（基于属性的访问控制，未来即将支持）

二、什么是 RBAC ?

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

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

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

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

三、使用 RBAC 的优势

• 系统性、可重复性的权限指派
• 更方便的用户权限审计，快速定位问题
• 快速地添加、修改角色，甚至可以调用 API 实现
• 减少授予用户权限时发生错误的可能性
• 引入第三方用户/新用户/未登录用户时，赋予他们预先配置好的角色，比如 guest 分组

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

• YES ：当前支持。
• In future release ：已加入未来规划，不久后将会支持。
• To be determined ：还在设计是否需要添加此功能。

五、RBAC 最佳实践：分组管理用户

除了直接赋予用户某个角色，作为 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: 具备申请假期的相关权限。
• • Corporation Email User: 具备使用公司邮箱的的相关权限。
• • Production Server Operator: 具备线上服务器的操作权限。
• • HR App User: 具备使用 HR 系统的相关权限。

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

• intern 具备 Corporation Email User 这个角色，但是不具备 Vacation Requester 和 Invoice Submitter 这两个角色。
• employee 拥有发票报销和申请假期角色，但是不具备线上服务器的操作权限。
• ops_engineer 拥有发票报销、申请假期、线上服务器的角色。

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

相关阅读

1. Authing 的故事：我为什么开发 Authing？
2. 如何在远程办公中保持高效的研发效率？
3. 一份普通人能理解的关于 Authing 的介绍
4. Authing 是什么以及为什么需要 Authing？
5. 为什么身份认证值得上云？
6. Authing @ 2019 总结
7. Authing 开发资源最全合集

重磅：Authing 将于2020 Q1 开源，欢迎 Star 关注 https://github.com/Authing/authing

什么是 Authing？

Authing 提供专业的身份认证和授权服务。
我们为开发者和企业提供用以保证应用程序安全所需的认证模块，这让开发人员无需成为安全专家。
你可以将任意平台的应用接入到 Authing（无论是新开发的应用还是老应用都可以），同时你还可以自定义应用程序的登录方式（如：邮箱/密码、短信/验证码、扫码登录等）。
你可以根据你使用的技术，来选择我们的 SDK 或调用相关 API 来接入你的应用。当用户发起授权请求时，Authing 会帮助你认证他们的身份和返回必要的用户信息到你的应用中。

<div align=center>Authing 在应用交互中的位置</div>

• 官网：http://authing.cn
• 小登录：https://wxapp.authing.cn/#/

• 仓库： 欢迎 Star，欢迎 PR

  • https://gitee.com/Authi_ng
  • https://github.com/authing

• Demo：

  • https://sample.authing.cn
  • https://github.com/Authing/qr...
• 文档：https://docs.authing.cn/authing/