權限管理的背景
權限管理的作用
迭代歷程
關鍵名詞釋義
權限管理模型
具體實現
寫在最后
權限管理的背景
在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少、邏輯清晰、擴展性比較強的權限管理系統。