2年前轉到SaaS部門之后期間斷斷續續做着權限相關的業務，這篇文章主要回顧下過往的設計以及其原因和利弊。
不過因為是線上業務，會省略掉很多細節以及賬號體系和權益相關得部分，只討論權限相關。
本文也不會涉及到技術層面的實現僅討論設計。
原初的混沌
SaaS和一些內部系統/2C業務的權限最大不同點是他是天然多租戶的。
用戶之上會有一層組織(Organization)的概念，組織只擁有所有權限的子集（取決於組織購買的服務），並且組織可以自行管理部分權限。
省略了部門，群組等等概念的簡化圖：
增加了組織概念：
剛接手的這塊的時候發現因為歷史原因設計得比較粗糙。
整個權限系統只有兩個表：權限定義 和 組織權限關系。
默認情況下組織內的所有用戶都能獲得分配給組織的權限，需要區分對待管理員和用戶的權限都是在代碼中進行硬編碼，手動去除對應權限。
當時的功能：
- 組織權限分配 - ACL
- 組織內用戶權限分配 - 硬編碼
這個模型嚴重限制了售賣策略和商家的靈活度，在系統中存在大量的硬編碼為了某個業務去修改權限的關系。
后續在這一版上勉強引入了組織內角色分配的功能，但因為業務設計過於簡單，沒法支撐后續的操作，最后決定重構。
業務場景驅動
這中間經歷了兩次模型的調整和服務的變更。
第一次想做和業務無關之后其他業務可復用的模型，基於RBAC構造了角色，角色"用戶"關系，角色權限關系；為了覆蓋ACL場景構建了"用戶"權限關系；為了多個業務方接入定義了domain，並且權限，"用戶"的定義和角色都和domain掛鈎。
對外提供的RBAC接口本質上是ACL，"用戶"分配角色，角色內權限變更會引起"用戶"和權限關系的變化。
至於為什么要這么設計，因為考慮到了一個分配角色后能手工修改用戶權限的場景，初步評估這個場景是有必要的。
為了保證"用戶"分配了多個角色后，如果存在同樣的權限點不會因為之后取消某個角色被全部取消了引入了refCount。
此時就存在了一個可以直接使用的ACL(obj_access_relation)和外觀看上去是RBAC（但其本質還是ACL）的基礎設施。
設置了兩個domain，針對組織依舊使用ACL，針對組織內的分配場景使用RBAC。
增加權限定義概念
在這之前要說明的是在設計時，組織中存在了一個管理員的概念，他不是某個角色，而是類似於組織creator的概念，其權限等同於組織的權限並且僅有一個，他的定義是為了簡化組織的管理，作為了這個組織的用戶層面映射。
權限定義這一概念的引入是為了應對組織內分配關系。
因為現在存在了組織和用戶兩個維度，分配關系最簡單的場景下會有幾種：
- 權限用於售賣，組織需要分配，用戶需要分配；
- 權限用於售賣，組織需要分配，用戶自動獲得；
- 權限用於售賣，組織需要分配，用戶不能獲得；（僅管理員使用）
- 權限用於管理用戶，組織自動獲得，用戶需要分配；
- 權限用於管理用戶，組織自動獲得，用戶自動獲得。(這個場景就不要用權限了）
- 權限用於管理用戶，組織自動獲得，用戶不能獲得；（僅管理員使用）
對於權限組織
權限定義內有兩個維度： 組織分配關系（默認獲得，需要分配），用戶分配關系（默認獲得組織的，需要分配，無法獲得）
經過實踐這一套不是特別方便：
- 不同domain需要定義不同的權限，但這個場景兩個domain下的權限其實是一致的；
- 過於業務獨立，一些業務場景自定義的東西難以插入其中，比如業務額外定義的權限定義表。
后續為了更好支持SaaS的權限系統把這套基礎設施復制到了SaaS權限內，這套基礎設施依舊留着給其他業務發光發熱。
到這一步的權限系統有如下幾個特性：
- 組織權限可通過權限定義和分配獲得，組織下存在一個管理者其權限等同於組織權限；
- 組織內用戶權限通過權限定義和角色分配獲得，並且約束用戶權限不能大於組織（防止組織的某個權限過期后其用戶還能繼續使用）；
- 存在系統預設的系統角色，出現條件為組織存在其角色依賴的權限；
- 組織可對其擁有的且定義為用戶可分配的權限組裝自定義角色分配給用戶。
針對用戶的高級功能。
上述特性中有提到用戶權限不能大於組織，這其實僅僅是針對組織域。
如果針對用戶層面販賣高級功能，就不能被這一層限制。
於是又引入了另一個域，其和組織域是正交的，雙方不存在邏輯層面上的關系。
也就是 管理員通過VIP獲得的權限不會影響到組織權限，用戶通過VIP獲得的權限不受到組織權限約束。
更多KA定制場景
做SaaS有一點比較困難的是KA需求，作為最重要的一批客戶，提供了大量現金流。KA的定制需求不能被忽略。
在迭代中增加了不少定制場景並泛化使用。
比如：
- 組織層面的權限定義，為了應對客戶嫌角色分配麻煩，可以組織內開關某個權限；
- VIP繼承組織權限設計，為了應對客戶在大量購買某VIP分配之后不想重復分配角色；
- 權限自動賦予某些部門下用戶
等等
這些問題的共同點就是分配行為的繁瑣。
之前引入的權限定義本身就是在組織分配層面解決這個問題，有了一些ABAC的特征。
在這些KA需求的迭代中也增加了更多subject attribute，例如組織ID，VIP類型，以及之后的更多拓展。
基於分配給用戶和解耦用戶直接分配的ACL和RBAC模型在這些領域都不能很好發揮，因為他們的作用前提是發生了分配關系，為了滿足更多的KA場景以及系統本身迭代會引入更多的ABAC元素。
之后的規划
現在線上運行的這一套系統已經和整個商業鏈路打通，客戶的服務購買/續期/增購會有一部分反應到權限系統中，新的功能需要商業化也都會統一接入其中，權限也從最開始的百來個發展到近千個。
但當前系統的不足也很明顯，整套體系的架構比較雜亂。
- 最開始做的偽RBAC那一套最后實踐沒有對應的場景，而且容易發生不一致的問題，需要在系統層面移除掉（但ACL本身保留）；
- ABAC實現零散且混亂，這一套要需要體系化重寫；
- 系統需要泛化到2C場景，打通2B和2C的商業化鏈路；
- 缺失了數據權限控制（object），但這一套應該不會和當前權限這一套做在一起，兩者的業務對象相差有點多（一個是組織用戶和功能，一個是用戶和各類數據）。
Written with StackEdit.