RBAC | 使用authing實現基於角色的訪問控制

時間 2020-02-06

標籤 rbac 使用 authing 實現基於角色訪問控制欄目軟件設計简体版

原文原文鏈接

1、認證 vs 受權？

首先讓咱們用一句話區分認證（Authentication）和受權（Authorization）：git

認證是識別請求方是誰的過程；
受權是知道了請求方是誰以後，判斷其是否具有某些權限的過程；

Authing 支持很是豐富的認證、受權手段：github

認證手段有：傳統密碼、驗證碼登陸、豐富的第三方登陸（微信、小程序、微博、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 時，經過分析系統用戶的實際狀況，基於共同的職責和需求，將他們分配給不一樣的角色。而後能夠授予每一個用戶一個或多個角色，每一個角色具備一個或多個權限，這種 用戶-角色、角色-權限 間的關係，讓咱們能夠不用再單獨管理單個用戶，用戶從具有的角色裏面繼承所需的權限，從而使得用戶賦權這件事變得更加簡單。segmentfault

舉一個公司內全部在職員工具有登陸公司郵箱的權限的場景，若是應用 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 等

用分組管理用戶、分組包含一組權限，這也是咱們推薦使用的方式。app

分組和角色的區別運維

分組(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（角色）管理權限，不要直接賦予單個用戶某個權限。若是是某個用戶臨時須要具有某個角色，能夠臨時授予，結束以後再收回。

什麼是 Authing？

Authing 提供專業的身份認證和受權服務。
咱們爲開發者和企業提供用以保證應用程序安全所需的認證模塊，這讓開發人員無需成爲安全專家。
你能夠將任意平臺的應用接入到 Authing（不管是新開發的應用仍是老應用均可以），同時你還能夠自定義應用程序的登陸方式（如：郵箱/密碼、短信/驗證碼、掃碼登陸等）。
你能夠根據你使用的技術，來選擇咱們的 SDK 或調用相關 API 來接入你的應用。當用戶發起受權請求時，Authing 會幫助你認證他們的身份和返回必要的用戶信息到你的應用中。