後台設計的基石：用戶許可權管理（RBAC）及工作流（workflow）模型

本文作者主要總結後台設計的基石：RBAC和workflow。enjoy~

後台產品同學在設計後台時，會發現一般後台的各個功能模塊總結起來有兩大類型：功能類、流程類。在設計功能或流程前都需要預判不同的使用角色對應不同許可權，設計流程前則還得思考最基本的工作流原理。

用戶許可權是設計後台普適的基本管理功能，設計系統時幾乎都需要考慮許可權問題。後台系統在面對不同部門不同崗位的人員時，如何區分授權？在考慮前端不同身份的用戶訪問時（如普通用戶、普通會員、超級會員），如何自動判斷許可權？工作流則是設計流程需要具備的基本理論，一個完整的流程會會包含哪些節點動作？節點是否可自主配置？

本文主要總結後台設計的基石：RBAC和workflow。

RBAC

1、什麼是RBAC

RBAC（Role-Based Access Control）基於角色的訪問控制。這是從傳統的許可權模型基礎上，改進而來並且相當成熟的許可權模型。這裡強調三個要素：用戶、角色、許可權。用戶與角色是多對多關係，角色與許可權是多對多關係。

傳統模型中無角色概念，直接為用戶賦上許可權，一是導致配置許可權相當麻煩，二來無法快速為多個用戶批量刪除許可權。用戶—角色—許可權多對多的關係，解決了這些問題。

關鍵元素：

• 用戶：成功認證並登錄系統的操作員（主體：who）
• 許可權：訪問資源的許可（how）
• 角色：許可權的集合體
• 資源：引入這第四個概念，包括系統菜單、頁面、按鈕等（what）

主體（who）如何通過許可權（how）訪問資源(what resource)。

許可權是用來訪問資源的，為用戶賦予許可權，則可訪問資源；在許可權基礎上，將許可權打包為一個許可權集合—角色，如財務經理角色，則為用戶賦上財務經理角色，用戶可訪問財務經理角色下的資源集合。

2、RBAC模型解讀

根據RBAC的複雜度不同，可分為RBAC0，RBAC1，RBAC2，RBAC3.最常用的為RBAC0.

（1）RBAC0模型

將一個或多個許可權掛到角色下，在將一個或多個角色賦予用戶，許可權與角色的關係，角色與用戶的關係，均是多對多的關係。

場景。為財務經理崗建立財務經理角色，將對賬、付款審批、回款確認等許可權配置在財務經理角色下，則公司再更換財務經理人員，只需每次為新來的財務經理配置財務經理角色。

為客戶經理建立客戶經理角色，客戶管理、客戶查詢、搶單等許可權配置在客戶經理角色下，適應於公司流動性高且佔比龐大（多的甚至上千人）的客戶經理群體，若某個許可權不適宜配置給客戶經理，直接在角色中刪除即可，無需分別對每個人進行許可權刪除。

（2）RBAC1模型

引入繼承概念，一個角色可以從另一個角色繼承許可權。角色間的繼承關係可分為一般繼承關係和受限繼承關係。一般繼承關係允許角色間的多繼承，受限繼承關係則進一步要求角色繼承關係是一個樹結構。

場景。適用於角色之間的層次明確，如總經理與副總經理，業務部門如總經理–團隊經理–業務員。也適用於用戶分級管理，初級用戶只能使用部分功能，中級用戶能夠使用更多功能。

（3）RBAC2模型

加入了角色的訪問控制。規定了許可權被賦予角色時，或角色被賦予用戶時，以及當用戶在某一時刻激活一個角色時所應遵循的強制性規則。

包括靜態職責分離SSD(Static Separation of Duty)和動態職責分離DSD(Dynamic DSD(Dynamic Separation of Duty)。

• 互斥角色 ：同一用戶只能分配到一組互斥角色集合中至多一個角色，支持責任分離的原則。案例：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色。
• 基數約束 ：一個角色被分配的用戶數量受限；一個用戶可擁有的角色數目受限；一個角色的許可權數目受限。案例：如VP類角色不可隨意分配給多個用戶。
• 先決條件角色 ：指要想獲得較高的許可權，要首先擁有低一級的許可權。案例：先有副總經理全下，才能有總經理許可權。
• 運行時互斥 ：例如，允許一個用戶具有兩個角色，但不可同時激活這兩個角色。

（4）RBAC3模型

RBAC1+RBAC2的集合體。即支持角色間的繼承關係，又支持角色間的責任分離關係。一般無需如此全面負責的模型。

3、關於一般角色、數據角色、成員角色

角色一般可拆分為一般角色、數據角色、成員角色。

• 一般角色：可見功能菜單頁、功能操作按鈕、數據欄位，均可通過顆粒度較細的許可權，去組合成一般角色。
• 數據角色：指可查詢的數據範圍。同一個一般角色，如查看客戶數據，大區總監能看到整個大區的數據，上海分公司經理只能看到上海客戶數據。上級組織職能看到下級組織員工負責的數據，而不能看到其他平級組織及其下級組織的員工數據等。
• 成員角色：新建成員即自動賦予的角色，即普通用戶均有的常規許可權，無需再手動配置。

4、常見的常規管理功能

（1）用戶管理

用戶按架構新建在對應的組織上。一般掛到機構→部門（一級部門–二級部門）下。

對於公司內部管理系統，管理用戶的前提，是需要合理的組織架構，只有支持組織架構的靈活配置，才能進一步支持組織內人員的增刪調整。

（2）角色管理

所有角色的管理功能。新建角色時，可將角色建立在某級機構或機構及以下，代表此角色只能適用此級別或此級別以下級別。

（3）菜單管理（有的後台叫欄目管理）

支持自主配置菜單一級二級，支持新增菜單、修改菜單、刪除菜單，更改菜單（修改菜單名、菜單順序等），每個菜單對應一個許可權。

（4）組管理

用戶所屬組，用於配置統一組同一部門用戶。有了用戶組，在新建角色時，可直接將角色賦予某個組，則進入此組的人員自動獲得對應角色。

workflow

一個業務流程包含多個環節的審批確認關係，按照業務流程，將各個節點串接起來，即時工作流。系統實現各個節點的自動流轉，解決手工處理工作流程的低效和失誤，提高工作效率的同時，還可通過線上直接流程狀況進行實時跟蹤，實現業務流程流轉的自動化。

1、工作流常見的路由方式

（1）串列路由

按順序一個步驟接著一個步驟走流程：

案例：入職流程，人力專員提交——HRBP審批——人力總監審批，順序走完流程。

（2）並行路由

同時可以執行多個不同的節點：

（3）條件路由

滿足條件後導向一個節點，不滿足條件的導向另外一個節點。

案例：流程提交滿足XX模式，則走A節點，不滿足則走B節點。

（4）分支路由

分支路由平行分支出多條線路，多條線路之間是並行的關係。

案例：付款申請，提交後判斷，對公付款走對公審批，對私付款走對私審批。

（5）合併路由

並行的多路分支集結到一個點的路由方式，前序分支節點全部都經過處理，最終才到匯合節點處理

案例：多個申請項目，同一天提交到終審崗審批。

（6）循環路由

下一步返回到原來的任意一個步驟，這之間形成的迴路就是一個循環路由。

案例：發起的流程，條到某崗位後，再流轉到自己確認，再提交。

（7）自由跳轉

這種是很特殊的路由方式，在流程實際運行時跳出原來定義的線路，自由跳轉到任意的步驟。

案例：滿足某個條件，則自動跳過某個崗位，無需此崗位再審批。

2、常見節點動作

• 提交：每個節點的人將流程提交至下手崗位。
• 回退：可退回到某個節點繼續流轉，退回到發起崗，或退回到前手崗。
• 撤回：節點執行完後、下一節點執行前，可以收回進行修改然後再提交。
• 取消/撤銷：流程發起人執行取消流程。
• 中止：流程提前結束，當前節點之後的其它節點不再執行。
• 審批：表單中的某個欄位，用於填寫審批意見。
• 會簽：通常用於審批後給相關的人簽字確認，需要簽字確認。
• 知會：指定的人知道有這個流程這麼回事，並能查看流程，不需要簽字確認。
• 加簽：審批時，可以徵求另一人或多人的意見，然後再回到原審批人。
• 跳簽：跳過接下來的一個或連續的多個節點，直接到指定的節點執行。
• ……

3、上報關係

每個節點提交後，下一節點將有誰審批？一般會為對應崗位的人員配置對應的節點。但若涉及到分公司或分地區審批，則需要設計上報關係。

上報關係支持靈活配置前一崗與後一崗的對應關係。如北京分公司的審批，提交到財務審核時，只能提交到北京財務部。合作公司的審批，只能提交到綜合財務部。此時就需要提前配置上報關係，北京分公司——北京財務部；合作公司—-綜合財務部。各個部門均可配置對應上報關係，包括財務，人力，業務等。

最後，為用戶配置某個財務部的許可權，則其僅可接收特定對應的上報關係的審批申請。如許可權為綜合財務部用戶，僅可收到合作公司提交的申請單。

BRAC和流程節點，在設計過程中，還需考慮其靈活性。

如操作員入職流程完畢後，自動賦予其崗位對應角色許可權，當然這可通過對用戶組分配角色實現。當操作員調崗時，根據調崗的跨度大小，自主確定是否更改許可權或刪除許可權。流程節點在系統中可根據對應業務，後台預備支撐性較強的節點變數，支持前台配置，由管理員自主根據對應業務流程，配置相應的流轉節點。

本文轉自：http://www.woshipm.com/pd/959125.html

推薦閱讀：