產品設計中往往會遇到在複雜產品結構中，用戶使用許可權的設定及後期維護問題，尤其是作為toB產品來說，牽扯運維、後台管理、複雜的組織架構、多戶類型等情況下，網站許可權邏輯複雜。無論是在產品開發還是後期維護過程中若沒有提前規劃好用戶許可權的分布能力，後期修改成本會非常之高。因此，一個完善的許可權系統是非常必要的。

而什麼是許可權設計系統呢？簡單來說就是：用戶與用戶可在此平台上的行為能力的關聯關係。目前關於許可權系統的設計主要是基於角色而進行的設計即為RBAC。RBAC(Role- Based access control,基於角色的訪問控制)是一種以用戶、角色作為主要關聯點的系統許可權控制系統，包含用戶、角色、許可權三大組成部分。這個系統可以簡單理解為一個用戶擁有若干角色，每一個角色擁有若干許可權。並且需要注意的是：用戶與角色之間、角色與許可權之間一般是多對多的關係。這種系統作為一種通用的許可權設計系統，對用戶許可權的規划具有指導意義但是卻不能完美解決真實系統中的許多問題,例如大批量用戶的角色分配、多許可權資源的管理問題等等。

前段時間參與的一個SaaS化產品開發與管理平台，因為介入了大量的用戶與角色，而每個用戶又都對應著不同的管理能力，這些能力與角色在真實工作中甚至有可能是重複或者交叉的，這些複雜的業務邏輯及角色變化急需一個簡潔的許可權系統進行梳理。因此，查閱了相關資料後，得出了一個基於RBAC的優化許可權系統。

在這個系統中，我將許可權規劃為以下基本元素：

用戶、群組、組織機構、角色、許可權、資源、操作。

用戶：每一個在此平台上進行創建的用戶賬號即默認為一個真實存在的用戶，同時為保證賬號信息的準確性與獨立性，減少同一用戶的註冊多個賬號造成的資源浪費，可在用戶註冊過程中作出一定的檢測限制，例如本次使用工號作為唯一識別碼，用戶可利用工號創建一個賬號，用戶信息由員工信息系統介面調用而來無需擔心姓名等信息的變換問題也避免了賬號重複。

群組：群組的產生主要是為了解決大量用戶的角色重複問題，需要注意的是用戶與群組既可以是從屬關係也可以是並列關係，即一個用戶可以被多個群組包含的同時作為獨立用戶存在。

組織機構：若存在用戶群組出現從屬關係的情況下，適當引入組織機構概念。組織機構的建立可以按照現有真實存在的組織架構鋪設，也可以完全新建。但是無論哪種方式都需要提前規劃好許可權的遞增或遞減規則，保證組織層級與許可權在邏輯上一致。

以上分類都是針對人進行的分類

角色：角色是用戶或群組在產品中擔任的職務能力,本質是【許可權的集合】。有的許可權系統，一個用戶只能有一個身份，但現實中一個獨立個體可能身兼數職所以一對一的模式會帶來後期能力擴展的限制。在此次許可權系統中，一個用戶可以對應多個角色，一個角色也包含多種許可權。目前規劃角色包含:平台管理員、DSV管理員、項目經理、測試經理、環境管理員、開發、測試等角色，後期針對這些角色分配不同的許可權能力。

許可權：可以簡單理解為能夠做某件事情的能力，在此許可權系統中,我將許可權分為「批量許可權】,「單一資源許可權】。批量許可權是針對角色或用戶、群組而進行的統一配置許可權，而單一許可權是針對某一特定用戶而進行的單獨配置。對於一個用戶來講，用戶的許可權集=用戶的「批量許可權」+用戶的「單一資源許可權」+用戶的所有「角色的許可權」。

另外用戶創建的資源時，可以獲得對應「單一資源許可權」的許可權。

資源：資源指代用戶在該平台中能夠獲得的支撐，常見的資源可以包含API介面、代碼組件、資料文檔等等，甚至網頁表單中一個輸入框都可以算作一種資源，對這些資源的讀取、編輯、提交等行為也需視為一種許可權能力。

操作：操作行為指用戶在平台中對資源進行變動的一切行為，包括但不限於新建、編輯、創建項且、引入人員等，這些操作將會對平台數據產生影響，繼而資源組成。

以上分類都是針對物進行的分類

許可權系統各因素關係如下圖所示：

小結：

1. 網站許可權系統的設計就要非常謹慎,既要考慮當前設計方案的嚴謹性,又要考慮後期的可擴展性。
2. 在進行網站設計之前，便需要依照產品定位構思許可權系統，且此時構思完系統框架後，還需要對界面展示、信息結構等交互細節做出梳理。
3. 對於業務邏輯不複雜，且後期不會出現大量業務擴展的產品，其實不需要設計此類許可權系統，代碼寫死可能是最簡單的方法。即許可權系統是按需供給，無需刻意為之。
4. 若後期系統繼續擴大，當前系統角色過於複雜時，可適當引入超級管理員角色持有所有許可權，作為最高層級來進行系統管理。但需要注意，超級管理員人數應盡量精簡。

推薦閱讀：