許可權管理的背景
許可權管理的作用
迭代歷程
關鍵名詞釋義
許可權管理模型
具體實現
寫在最後
許可權管理的背景
在OA辦公軟體篇（一）—組織架構一文中，我們說到組織架構是軟體系統的許可權體系的重要搭建依據，軟體根據不同員工在組織中的位置給予不同的許可權，比如說普通員工對於軟體只有檢視和使用的許可權，普通管理員對於軟體有檢視和修改的許可權，超級管理員則擁有最大許可權等。這一篇文章就將移動端和管理端結合結合起來講講許可權體系搭建的一些方式和使用效果做一個講解。
百度百科上面關於許可權管理的解釋為：“許可權管理一般指根據系統設定的安全規則和安全策略，使用者可以訪問而且只能訪問自己被授權的資源，不多不少。許可權管理幾乎出現在任何有使用者和密碼的系統。”由此可見，許可權管理實質上就是一系列規則和策略，幫助系統很好的規範使用者“行為”，系統不讓做、不讓看的使用者就無法操作和獲知。
許可權管理與“使用者身份認證”、“密碼加密”、“系統管理”等概念不同，不要混淆了。使用者身份認證解決的是“你是誰”的問題；密碼加密隸屬於使用者身份認證領域；系統管理一般是系統的一個模組，該模組會包含許可權管理子模組，但系統管理的許可權管理，只是一個操作介面，讓管理人員能夠設定角色等安全策略。
許可權管理的作用
古人云：“無規矩不成方圓”，許可權管理就是規矩的一種，它限制人們做事情的範圍，保證大家之間不會產生衝突，使得系統能夠有序執行。
對於企業而言，對員工進行許可權控制和管理的根本目的還是在於使公司能夠有效和高效的運轉，具體體現在以下三點：
（1）能夠保證員工各司其職，每個人所負責的內容不一樣，互不干擾，從而提升工作效率。
（2）每個人負責的工作範圍具體而明確，責任到人，權責分明，出了問題有據可查。
（3）不同的人負責的工作重要程度不同，如機密事項只能少數人知曉，能夠保障隱私，從而規避風險。
迭代歷程
一般我們們做許可權管理系統，基本上只會涉及到一個端的許可權管理問題，原因為通常只有後臺管理端涉及的頁面和管理項操作需要進行許可權管理，移動端則不涉及到太多許可權管理的問題，比如醫療產品，移動端使用者使用使用者名稱和密碼做身份驗證，正常使用就好了，不需要再給使用者分層分許可權。
OA產品則比較特殊，在整個產品執行體系中，各個端都會涉及到許可權管理系統，這個原因究其根底還是因為OA系統的使用者層級分明，架構龐雜，如果是行業專用OA則會更加複雜（我目前所在OA產品就是醫藥行業專用OA）。移動端的使用者需要根據使用者許可權決定其能否進行流程審批、功能使用等。
1. 先說一下移動端
在上一篇文章《OA辦公軟體篇（一）—組織架構https://www.cnblogs.com/zshsblogs/p/15991723.html》中，我們探討了普通員工和管理人員究竟是採用兩個獨立移動端來實現還是使用一個來實現的問題，這裡面充分反映出來在移動端許可權管理這一塊，該產品進行了怎樣的迭代過程。
第一個階段：OA產品用兩個端實現，以身份代替許可權，將普通員工和管理人員按照兩個端模式嚴格進行功能區分，不同賬號、不同埠登入使用不同的身份驗證方式，同一端內的功能使用則僅按照規則內建的方式進行簡單的“許可權控制”。
第二個階段：兩個端合為一個端，重新梳理和定義不同角色在同一功能下的表現形式，重塑許可權體系。
第一個階段和第二個階段相比，許可權管理不成體系，功能許可權無法明確有效的控制，造成的後果就是管理不清晰，無法“權責分明”，比如管理端的日誌抄送配置功能所有管理端使用者都可以進行操作，出錯後無法追溯；隱私性比較差，比如業務資料和客戶資訊所有管理端成員都能夠無差別的看到。
這裡就不得不說，千萬不要為了一時的利益就枉顧產品設計和迭代的基本原則，為了完成任務而完成任務的結果就是，後來的產品經理和研發拿著一堆食之無味棄之可惜的產品功能反覆權衡，既不想付出過多的人力和時間大幅度整改，又不得不在一盤散渣的基底上來回摩擦，最後不得已走上重構的路。
2. 再說一下後臺管理端
在我目前所在的這個OA產品中，受研發資源的影響，後臺管理端一直沒有規劃設計和開發過，所以整個後臺管理系統都是由我從0到1設計、研發並投入使用的。後臺管理端在這裡起到的作用是便於行政和管理人員的使用，比如日常考勤資料匯出、審批統計等。後臺管理端未走彎路，一氣呵成。
關鍵名詞釋義
先來看幾個許可權管理相關的名詞解釋。
（1）許可權管理系統定義
許可權管理系統是許可權管理的具象表現形式，主要進行角色管理、使用者管理、賦權、使用者追溯等工作。
（2）角色
角色代表某一類人，不特指某一個人，角色最好採用職位或者抽取人群共性進行命名，比如市場部員工角色、銷售部主管角色，便於理解和使用。
（3）許可權
許可權分為：頁面許可權、操作許可權和資料許可權。頁面許可權控制能夠看到哪個頁面，操作許可權控制能夠操作頁面上的哪些功能按鈕等，資料許可權則控制你能夠看到哪些資料。
許可權管理模型
大部分涉及到許可權管理的產品都會涉及到一種模型：RBAC（Role-Based Access Control）模型，基於角色的許可權訪問控制，它將who、what、how進行了關聯，解釋了誰（who）對什麼（what）做了怎麼樣操作（how）的問題。RBAC包含四個子模型，分別是RBAC0、RBAC1、RBAC2和RBAC3，他們的核心思想都是相同的，只是存在部分差異。
RBAC0是基礎，其它三個子模型都是由他演化而來，在他的基礎上各自進行變形。RBAC0最顯著的特點就是人不直接與許可權相關聯，而是通過角色這一中間介質，獲取系統的許可權。在這個模型中，角色與許可權之間屬於多對多的關係，使用者所擁有的許可權等於他所擁有的所有角色下的許可權的總和。RBAC0中的使用者、角色和許可權的關係如下圖所示：
RBAC1是在RBAC0的基礎上，增加了角色分層和角色繼承的能力，一個角色擁有不同的等級，不同的等級擁有不同的許可權。通過角色分級，可以實現更精細化的管理。角色和許可權的關係如下圖所示：
RBAC2是在RBAC0的基礎上增加了一些對角色和許可權的限制。分別是角色互斥限制：當系統中有多個角色的時候，使用者只能擁有/啟用他們中的一個角色；角色基數限制：限制使用者只能擁有或者啟用一定數量的角色，限制角色只能被賦予一定數量的許可權；先決條件限制：當使用者想要擁有一個角色的時候，必須擁有另一個角色才可以，或者當角色想要擁有一個許可權的時候，必須要擁有另一個許可權才可以。
RBAC3是RBAC1和RBAC2的合集，同時擁有這兩個模型的所有特點，他們的關係如圖所示：
具體實現
在這裡我們不再一一介紹移動端的實現過程，僅用管理端為例說明許可權管理的實現過程。
在進行許可權管理系統設計之前，首先需要根據實際情況明確使用的是哪一個模型，都有哪些限制等。我這裡根據當前OA的使用和擴充情況採用RBAC0進行實現，同時採取了角色互斥的限制。
（1）角色管理
角色管理是許可權管理的第一步，主要分為角色建立、角色刪除、角色許可權分配三個功能點，如下圖所示：
（這裡因為醫藥OA多公司使用的特性，因此角色也會分為總公司角色和普通公司的角色）
後臺管理端許可權分配這裡僅涉及頁面許可權分配，資料許可權直接使用的是預設規則，而操作許可權則是因為不太必要所以沒有進行處理。
（2）使用者管理
使用者管理這裡涉及到兩種模式，一種是直接從組織架構中獲取使用者進行許可權控制，如下圖所示：
一種是非組織架構使用者需要新增管理，如下圖所示：
一般情況下，組織中的頂端（董事長、總經理）及部分特殊崗位擁有超級管理員的許可權，組織中的管理者（中層管理人員、普通管理人員等）擁有普通管理員的許可權，組織中的一般員工為一般使用者許可權。除了按照組織進行預設的軟體許可權的劃分，支援手動的許可權劃分和管理也是軟體的一項重要的功能。當然，許可權體系的劃分邏輯不僅限於此，重要的是許可權體系的擴充套件性！
為使用者設定角色，如下圖所示：
（3）行為追溯
為了進行使用者行為追溯，將使用者行為日誌進行記錄。
（4）管理端對移動端的相關管理
根據部門對移動端功能許可權和資料許可權進行管理，一個部門相當於一個角色。
寫在最後
理解清楚RBAC模型，許可權管理並不難。通常我們都是用現成的管理後臺，這一部分的設計往往被產品經理忽略，但實際上，只要涉及到產品的從0到1，許可權管理就是必須要考慮的重點事項，因此一定要懂。而對於技術來說，也只有理解清楚許可權管理的核心邏輯，才能夠做出BUG少、邏輯清晰、擴充套件性比較強的許可權管理系統。