MASA Auth
使用者
在系統裡，使用者是一個核心概念。它代表了一個人的唯一身份標識，除了與角色、團隊、組織架構等有關，甚至還會影響到在同一個介面不同的使用者操作流程與顯示內容都會發生變化，再複雜一點的話，或許在同一個系統內的一個使用者進入到不同產品後的身份也會變化
使用者與角色
使用者可以擁有一個或多個角色，讓角色作為許可權組，將一組或多組許可權間接的分配給使用者
使用者與團隊
使用者可以在多個團隊中，每個團隊可以擁有一個或多個角色，將一組或多組許可權通過角色與團隊關聯，並賦予團隊內的成員
團隊內成員可以是內部的，也可以是外部的。通過統一的使用者表作為人的唯一身份標識。再通過Employee和ThirdPartyUser區分使用者身份屬性。
使用者與組織架構
使用者可以被指定在組織架構的某一個節點中
但組織架構是一個虛擬的樹形結構，它歸屬於業務，所以沒有與許可權直接關聯
除此之外，組織架構有時候很難表示角色繼承關係。在同一個組織架構節點中的不同成員常常會具有不同的角色，且上下級關係也未必會作為上下級節點緊貼在一起。有部分公司上下級之間可能隔了幾個層級
組織架構在我們早期定義中是與許可權關聯且沒有團隊這個概念的。但實際上專案制在很多公司內部都存在，以專案制執行時，人員的許可權和虛擬組織關係會頻繁變化。導致常常要在組織架構調整和大量個人許可權微調上做抉擇，為了徹底解決這種割裂的行為。我們把組織架構看作虛擬的樹形結構來描述每個人的部門歸屬權，同時採用團隊的方式解決專案制下人員頻繁進出和四處作戰而引發的許可權變更問題
使用者與許可權
使用者除了擁有角色以外，可能還存在個別特殊業務下需要臨時性授予或禁用部分許可權
雖然與RBAC2有一點衝突，但事實上這樣的場景的確存在，比如即將離職的財務需要臨時收回付款功能，這裡明顯要違背互斥原則，在設計上我們的選擇是擴充套件許可權的優先順序高於角色內包含的許可權。這樣可以通過對衝達到收回部分敏感許可權的功能
使用者型別
使用者有三種型別：終端使用者，員工，駐場員工
舉個例子：
- A是公司員工，擁有內部許可權。同時也是公司產品的終端使用者
- B是駐場員工，擁有部分內部許可權。同時也是公司產品的終端使用者
使用者許可權優先順序
使用者的許可權應該具有一定的優先順序，來解決同一個業務下多個許可權同時生效時系統該選擇啟用哪一個
我們將採用以下規則：
-
超級管理員/管理員
超級管理員為系統管理員，管理員為指定專案的管理員
-
使用者的擴充套件設定許可權
-
使用者的角色許可權
使用者的角色許可權衝突時，拒絕優先順序高於允許，低於使用者的擴充套件設定許可權
-
團隊的預設角色許可權
-
團隊中的父級角色許可權
將來在團隊支援上下級關係後，當前使用者沒有被分配到許可權，且當前團隊存在父級時將向上遞迴查詢距離最近的預設角色來獲得許可權列表
使用者許可權型別
使用者的許可權型別大概分為四類
-
選單：是否可以通過選單存取某個頁面
-
頁面元素：是否可以對頁面內的元素進行操作，如按鈕。頁面元素需要掛在選單下
-
資料：是否顯示指定欄位。資料需要掛在選單下
資料與頁面元素類似，但與頁面元素之間相互獨立
-
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，歡迎聯絡我們
