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

1、认证 vs 受权？

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

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

Authing 支持很是丰富的认证、受权手段：

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

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

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

2、什么是 RBAC ?

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

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

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

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

3、使用 RBAC 的优点

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

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

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	默认为否

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

5、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/