RBAC架構 Role 與 Menu 的設計規劃 (上)

使用者登入後，由角色來控制顯示的選單、頁面和 API 呼叫權限

從2020年加入專案，到現在已經正式上線半年了，用戶與Tsp合作業者也穩定(?)成長中。這邊將當初的需求和設計規劃記錄下來，也當作此次的工作經驗整理。

首先還是要從PM的需求說起......

「我們目前是規劃三個平台，企業端、用戶端和系統端。」 PM說。
「任何平台登入後左側需要一個選單，選單展開後能看到不同的頁面。」
「那選單要長幾層？」我問到。
「目前規劃是一層選單一層頁面就好。」
「恩。」
「不同的使用者，根據權限不同會看到不一樣的選單和頁面。」
「每個頁面裡會有各種區塊，不同的用戶也會看到不一樣區塊。」
「是區塊裡的東西查無資料不顯示嗎。」
「不是，是每間企業會購買不同的服務，只顯示他們有購買的服務區塊，這在系統端要可以設定。」
「不過沒資料的話區塊不顯示也要做到。」
「喔喔。」
「還有如果企業的合約到期，他們旗下的員工就都不可登入。」
「另外考慮到企業的管理者loading太大，也要設計讓他能將自己的權限授權出去。」
「我覺的頁面拆分讀寫的存取權限。」 SD突然插話。
「就是頁面根據權限會有修改或唯讀的功能吧。」
「對。所以權限要細分到API。」
......

好吧大概是這樣，整理了一下需求。

1. 要長出三組選單，分別對應三種平台
2. 選單下串接頁面
3. 根據不同的權限，選單可見的區域也會不同
4. 頁面內的區塊也要被權限控制
5. 權限要有時限
6. 系統端可對企業端授權，企業端亦可對企業端授權，但權限會限縮
7. 控制頁面的讀與寫也需由權限控制
8. 要檔下沒權限直接打API的情況

先從選單(Menu)的架構開始規劃

這邊設計能讓[選單串接選單]和[選單串接頁面]，比需求還要多做了一些，算是防患未然吧。

而[頁面串接頁面]，主要是解決需求 3 ，讓前端能把區塊當成頁面來控制是否要顯示。至此需求 1 到 4 大致都能滿足了。

再來要設計角色(Role)的權限綁定了，將角色與頁面能多對多的綁定。讓一個人可以擁有多個角色，每個角色又可以有多個頁面的權限。

上圖為角色綁定頁面的例子；前端將控制灰色部份不顯示。

當用戶被賦予多個角色時，只需將所有角色綁定的頁面取「聯集」，再根據聯集的頁面組出對應的選單即可。

而API的呼叫權限，可以從綁定的頁面來取得。因此只要先檢核用戶擁有的角色，是否有權限使用本次呼叫的API即可，藉此需求 8 也滿足了。

至於需求 6 的實作概念也滿簡單的；在系統端授權時，理所當然可授權的清單是所有的頁面；而企業端的管理者要授權時，僅能讓他選擇自己有權限的頁面即可。

而需求 5 和 7 ，在設計資料庫時會使用欄位來進行控制，以及需求 8 在通過微服務BFF(Backend For Frontend)的相關檢核過程，都會記錄在下一篇。