轉載至：http://www.sohu.com/a/340431910_695183
產品經理在思考產品架構的過程中，必須要有業務流程的參與。通過業務流，常常會抽象出對產品有訴求的多個角色，再依據角色的特性去梳理使用場景並設計需求。
當角色之間的使用場景不沖突，不需要隔離時，我們會綜合考慮這些角色的使用場景來設計解決方案。比如QQ音樂同時需要為聽歌和聽電台的用戶提供所有的功能需求。
當這些角色的使用場景完全不重疊、流程對立時，我們會設計完全獨立的兩套系統，如微店賣家端和買家端；
除了上面兩種情況，在toB產品中，基於產品流程和信息安全等多符合因素考慮， 各個角色的使用場景是部分通用，部分隔離的，這時候就需要引入“權限系統”了。
涉及到權限的問題往往是都是復雜的問題，在系統權限控制方面，我們經常會參照現成的案例來設計自己的權限控制，以下就是John所總結最常見的四種權限控制的方法。
一、控制系統的帳號及登錄
1. 帳號的定義
基本上所有的互聯網產品，無論是移動端、PC端、C端或B端產品，登錄都需要一個賬號。只是對於C端的產品，都是用戶自己注冊即可。
而對於后台產品而言，是需要公司內部人員去創建賬號的。而這個賬號就是一把鑰匙，我們通過控制賬號所具備的權限，進而控制這個員工的所操作區域。
2. 帳號的層級：企業（管理員）帳號、普通帳號
公司的實際運營人，他應該掌握最核心、權限最大的企業帳號，所以也可以稱為“管理員帳號”俗稱admin賬號，其他都為普通帳號。
在實際系統中的核心業務步驟如下：
-
企業搭建系統時，默認會用admin作為系統賬號的最高權限。下級可以創建企業賬號（依托於權限）。
-
在部署培訓階段，可指導企業賬號持有人創建一個或多個普通賬號（可是給其帳號授權管理員角色），后續配置即由管理員賬號進行。
（魅族的小伙伴可以說下，魅族論壇賬號為“J.Wong”是不是admin的權限。哈哈哈哈）
在用戶狀態上加狀態控制，可用的用戶就可以登錄系統，禁用、停用的就無法登錄。
二、角色管理角色
往往是基於業務管理需求而預先在系統中設定好的固定標簽，每個角色對應明確的系統權限，他是一個集合的概念，是眾多最小權限顆粒的組成。我們通過把權限給這個角色，再把角色給賬號，從而實現賬號的權限，因此它承擔了一個橋梁的作用。引入角色這個概念，可以幫助我們靈活的擴展，使一個賬號可以具備多種角色。
其所擁有的系統權限一般不會隨意更改，並且角色也不會隨着用戶的被添加和被移除而進行改變，相較於用戶管理而言更加穩定。
而引入“角色”概念后，用戶與角色之間的關系鏈是怎么樣的？這兒引用一個模型：RBAC模型（已經被大家寫文章用壞了，可能有些小伙伴還是懵逼），John這邊貼上百度百科解釋下：
基於角色的權限訪問控制（Role-Based Access Control）作為傳統訪問控制（自主訪問，強制訪問）的有前景的代替受到廣泛的關注。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合並而賦予新的權限，而權限也可根據需要而從某角色中回收。角色與角色的關系可以建立起來以囊括更廣泛的客觀情況。
簡單點一句話說下：Who（權限的擁有者或主體）對What/Which（權限針對的對象或資源）進行How（權限針對的對象或資源）操作。
上圖示意為：用戶與角色可為多對一或多對多的關系，當一個用戶的角色為多對多時，當前用戶的權限是多個角色的並集。
此時只需要為角色賦予權限，能夠大大減輕管理負擔，同時將用戶與權限解耦，提供更大的靈活性。
由於隨着公司擴大角色的增多，試想如果用戶量上萬，新增一個角色時，可能需要為大量用戶都分配一遍新的角色，工程量仍然巨大，此時即可以引入用戶組的概念：如果部分用戶的使用場景是相對一致和基礎的，我們可以把這些用戶打包成一個組，基於這個組的對象進行角色和權限的賦予。
同理如果權限較多時也會存在一樣的問題，處理方式是引入權限組的概念，將使用場景相對固定的一組功能或權限打包成組賦予角色。但是一般來講一個系統中權限功能的體量是相對有限和可控的，所以實際應用中對權限組的使用較少。
用一個頁面例子來解釋下：
（用戶組）
（用戶管理）
（用戶權限&權限組）
三、控制功能權限（案例）
功能權限定義：為可見、可以操作的功能范圍。例如：某一部分目錄，或者某個頁面里的各種操作。
1. 目錄管理模塊
類型分為2種：目錄、操作。
在目錄上加權限控制，有權限的就可以訪問對應模塊。
在業務模塊的功能按鈕上加權限控制，最小粒度的控制用戶行為。例如：上級有錄入商品的權限，就能看到商品錄入的操作，點擊錄入就可以進行商品的錄入操作；反之沒有該權限的下級就無法進行商品錄入的操作。
（紅色的代表目錄，藍色的代表操作）
2. 控制功能權限管理
底層目錄管理配置一般為開發人員一早就配置好，現在由用戶進行分配使用這些功能權限。
功能權限：以角色為基礎，通過划分不同角色的不同功能權限，並將員工添加到對應的角色中，實現員工功能權限的區分和隔離，包括：
-
對象級功能：比如功能的入口是否可見，如角色為“人事HR”，對“人員管理”的“查看列表”權限點取消，則此角色下員工不可見人員管理的功能入口。
-
操作點權限：比如新建、編輯等業務操作；
字段權限：在展示信息時加權限控制，保證敏感信息的安全性。可為角色配置對象字段的讀寫、只讀或不可見。比如：為角色“服務人員”配置銷售訂單的【銷售訂單金額】字段不可見。
（字段權限細節）
-
【讀寫】權限：員工將具備該字段的最大權限，【新建】【編輯】時可編輯，列表和詳情頁可見該字段。
-
【只讀】權限：員工在【新建】【編輯】時不可編輯，列表和詳情頁可見該字段。
-
【不可見】權限：員工在【新建】【編輯】【列表】【詳情】界面對該字段（或該字段值）不可見。
功能權限對於前端界面的影響點：
-
如果員工沒有某對象“查看列表”的權限，則該對象的功能入口會被隱藏。
-
如果員工沒有某對象的操作點權限，則在對象頁面上隱藏相應操作按鈕。
-
如果員工沒有某對象的指定字段的可見權限，則在對象頁面上隱藏相應字段。
總結下：在權限管理中，需要遵循的一個重要的點：用戶移動要匹配對應的操作。
四、配置權限注意點
產品設計支持后，配置權限需要注意以下幾個要點：
1. 確定是否支持前端配置
如果角色和權限相對固定，則一般將角色與權限的關系可以寫在后台，改動時需要后端變更且重新上線；這種情況適用於公司內部系統等只有一個使用主體的系統。
如果需要自定義角色、或者每個角色在不同使用者的場景下有不同的權限，則需要將角色的定義、角色與權限之間的配置體現在“前端用戶配置頁面”；這種情況適用於有頻繁變動的自定義角色權限，和有租戶體系的系統。
2. 以基本單元拆分，以業務邏輯配置
一般可將每個對象的“增、刪、改、查”各自作為一個基本的權限單元。打個比方，在“人員管理”中，查看人員列表、添加人員、刪除人員、編輯人員信息最好拆分為4個權限單元。在技術和設計上，我們希望能盡量做到解耦和模塊化。
但是在業務層面有些操作卻是一體的。這些不能拆開的權限在“前端用戶配置頁面”中建議打包成一個整體提供配置。例如，如果我們確定在系統的現有和未來業務中，僅分為普通成員有“人員管理”的查看權限，管理員有操作權限，則可將“增、刪、改”三個基本權限單位合並為“操作”權限進行配置。
3. 頁面權限優先於操作和數據權限
必須配置了頁面模塊權限后，才能配置當前頁面模塊下具體的操作權限，以及頁面模塊的數據展示權限；
4. 查看權限優先於增刪改權限
正常情況下，一定要先能查看某個模塊或操作，其它的增刪改操作才有意義。因此在設計時，應在獲取查看權限前限制其它權限的配置；或者配置其它權限時默認賦予查看權限。
5. 角色與權限的多種關系
角色與權限的關系不僅是單純“是/否關系”，還包括以某種限制進行操作，和以某種程度訪問數據。例如在“人員管理”中：
-
數據范圍：用戶擁有查看人員列表的權限，但僅能查看自己所在的團隊；
-
數據邊界限制（上限等）：添加人員時不能超過20個等。
-
數據字段：HR能查看人員列表中包括職級、薪資等字段；其它角色僅能查看姓名郵箱等字段；
6. 角色與權限的設計表達
在傳達一個系統的權限設計規則時，設計師常常習慣用主觀最直接的方式表達想法，如用“當……時，就……”的句式來表達。但一個平台中涉及的權限規則是非常多的，當通篇以這樣的形式描述時，表達對象將很難理解。
正確的描述方式：更清晰的是基於開發的語言，和技術模型的結果進行表達：將各角色與權限單元繪制成網格，每個交叉點網格中描述該角色與權限的數據關系和限制。
五、后台產品邏輯自查表
后台產品邏輯遵循的就是八個字：“增（增加）”、“刪（刪除）”、“改（修改）”、“查（查詢）”、“顯（顯示）”“算（算法）”、“傳（傳遞）”和“異（異常）”。用一張表來整體看下自查表：
后台權限不復雜，用戶角色和權限一一對應匹配就好了。同樣前端后台都不復雜，只要真實清楚的去了解業務就好了。