用戶
在系統里，用戶是一個核心概念，它代表了一個人的唯一身份標識，除了與角色、團隊、組織架構等有關，甚至還會影響到在同一個界面不同的用戶操作流程與顯示內容都會發生變化，再復雜一點的話，或許在同一個系統內的一個用戶進入到不同產品后的身份也會變化
用戶與角色
用戶可以擁有一個或多個角色，讓角色作為權限組，將一組或多組權限間接的分配給用戶
用戶與團隊
用戶可以在多個團隊中，每個團隊可以擁有一個或多個角色，將一組或多組權限通過角色與團隊關聯，并賦予團隊內的成員
團隊內成員可以是內部的，也可以是外部的，通過統一的用戶表作為人的唯一身份標識，再通過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，歡迎聯系我們
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/487819.html
標籤：.NET技术