MASA Auth - 從用戶的角度看整體設計

用戶

在系統里，用戶是一個核心概念。它代表了一個人的唯一身份標識，除了與角色、團隊、組織架構等有關，甚至還會影響到在同一個界面不同的用戶操作流程與顯示內容都會發生變化，再複雜一點的話，或許在同一個系統內的一個用戶進入到不同產品後的身份也會變化

用戶與角色

用戶可以擁有一個或多個角色，讓角色作為許可權組，將一組或多組許可權間接的分配給用戶

用戶與團隊

用戶可以在多個團隊中，每個團隊可以擁有一個或多個角色，將一組或多組許可權通過角色與團隊關聯，並賦予團隊內的成員

團隊內成員可以是內部的，也可以是外部的。通過統一的用戶表作為人的唯一身份標識。再通過Employee和ThirdPartyUser區分用戶身份屬性。

用戶與組織架構

用戶可以被指定在組織架構的某一個節點中

但組織架構是一個虛擬的樹形結構，它歸屬於業務，所以沒有與許可權直接關聯

除此之外，組織架構有時候很難表示角色繼承關係。在同一個組織架構節點中的不同成員常常會具有不同的角色，且上下級關係也未必會作為上下級節點緊貼在一起。有部分公司上下級之間可能隔了幾個層級

組織架構在我們早期定義中是與許可權關聯且沒有團隊這個概念的。但實際上項目制在很多公司內部都存在，以項目制運行時，人員的許可權和虛擬組織關係會頻繁變化。導致常常要在組織架構調整和大量個人許可權微調上做抉擇，為了徹底解決這種割裂的行為。我們把組織架構看作虛擬的樹形結構來描述每個人的部門歸屬權，同時採用團隊的方式解決項目制下人員頻繁進出和四處作戰而引發的許可權變更問題

用戶與許可權

用戶除了擁有角色以外，可能還存在個別特殊業務下需要臨時性授予或禁用部分許可權

雖然與RBAC2有一點衝突，但事實上這樣的場景的確存在，比如即將離職的財務需要臨時收回付款功能，這裡明顯要違背互斥原則，在設計上我們的選擇是擴展許可權的優先順序高於角色內包含的許可權。這樣可以通過對沖達到收回部分敏感許可權的功能

用戶類型

用戶有三種類型：終端用戶，員工，駐場員工

舉個例子：

• A是公司員工，擁有內部許可權。同時也是公司產品的終端用戶
• B是駐場員工，擁有部分內部許可權。同時也是公司產品的終端用戶

用戶許可權優先順序

用戶的許可權應該具有一定的優先順序，來解決同一個業務下多個許可權同時生效時系統該選擇激活哪一個

我們將採用以下規則：

1. 超級管理員/管理員

   超級管理員為系統管理員，管理員為指定項目的管理員

2. 用戶的擴展配置許可權

3. 用戶的角色許可權

   用戶的角色許可權衝突時，拒絕優先順序高於允許，低於用戶的擴展配置許可權

4. 團隊的預設角色許可權

5. 團隊中的父級角色許可權

   將來在團隊支持上下級關係後，當前用戶沒有被分配到許可權，且當前團隊存在父級時將向上遞歸查找距離最近的預設角色來獲得許可權列表

用戶許可權類型

用戶的許可權類型大概分為四類

• 菜單：是否可以通過菜單訪問某個頁面

• 頁面元素：是否可以對頁面內的元素進行操作，如按鈕。頁面元素需要掛在菜單下

• 數據：是否顯示指定欄位。數據需要掛在菜單下

  數據與頁面元素類似，但與頁面元素之間相互獨立

• API：是否可以訪問指定API。API一般需要掛在菜單或頁面元素下，如有需要也可以掛在數據下

許可權層級

總結

至此，我們從一個用戶的角度將角色和許可權，前端與後端都串聯了起來。但到目前為止還是概念的梳理階段，做好一個許可權中心很難。每個團隊有自己的管理方式，如何在不同的團隊需求中摘取到共同點把主線串聯起來，既能滿足絕大部分場景需求又留有擴展餘地仍然需要時間去驗證。

（本文章不代表最終設計）

參考：

https://uxdesign.cc/design-permissions-for-a-saas-app-db6c1825f20e

開源地址

MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks

MASA.Contrib：https://github.com/masastack/MASA.Contrib

MASA.Utils：https://github.com/masastack/MASA.Utils

MASA.EShop：https://github.com/masalabs/MASA.EShop

MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor

如果你對我們的 MASA Framework 感興趣，無論是代碼貢獻、使用、提 Issue，歡迎聯繫我們