背景産品設計，使用者角色權限系統（賬戶管理）
一、RBAC權限設計模型（就是文章封面圖這個東西）
RBAC（Role-Based Access Control），中文就是基于角色的通路控制，這是目前最為廣泛接受的權限模型。在RBAC中，權限與角色進行關聯，權限不與使用者之間關聯，使用者通過成為角色中的成員進而獲得該角色所對應的權限。是以，假如一個使用者擁有多個角色，他就擁有多個角色的功能權限。
偷偷從網上扒了一個模型關系圖：
二、産品如何設計
了解完RBAC後，很多都會覺得一個背景的使用者權限系統大緻可劃分為：使用者管理、角色管理、權限管理這三大子產品，對吧？
但是，現實往往沒那麼簡單，使用者管理與公司行政部門或業務線強相關，對應的部門或者業務小組内的使用者又有着極為相似的基本功能需求和權限。是以在這裡我會建議加入多一個子產品：部門管理，作為使用者管理的分組。
okay，文章重點來了，一個背景權限系統，應該有四大子產品：部門管理、使用者管理、角色管理、權限管理。為了使用者更好了解角色和權限，實際産品設計中（角色管理和角色賦予權限結合在一起），使用流程如下：（以下内容将依據流程逐漸講解）
1.部門管理
顧名思義，就是背景中使用者所在的部門，可以按行政關系（部門架構）、業務部門（業務關系）來劃分設計。因為使用者的資訊中就會帶上部門的資訊，同部門或同業務的使用者就可以授予相同的角色進而獲得權限。
産品設計如下：
部門管理-産品設計
在部門管理中，可以清晰地看到各個部門或業務之間的關系，也便于規劃不同部門之間的資料權限。
2.角色管理+角色的權限管理
有了整體的部門架構，那麼每一部門對應的角色有哪些呢？同個部門中，是否有多個角色呢？是以就需要角色管理（添加、編輯、删除角色）來管理每個部門中的角色及角色的資料權限範圍。比如：營運部中，有營運總監（可檢視到整個部門所有人的資料）、營運組長（可檢視營運A組的本組全部資料）、營運專員（可檢視個人資料）。那麼一個營運部門至少就有三種角色：營運總監、營運組長、營運專員，三種角色也對應三種不同的權限。
角色是基于業務管理需求而添加的固定标簽，每個角色對應明确的系統權限，其所擁有的系統權限一般不會随意更改，并且角色也不會随着使用者的被添加和被移除而進行改變，穩定性強于使用者管理。
通過“關聯權限”來給角色賦權，也就是角色的權限管理。
添加角色——産品設計
角色賦權—關聯權限
3.使用者管理
部門設定了，角色和權限也設定了，那麼使用者應該要被添加上角色名稱了，進而獲得相對應的權限了。
因而通過“添加使用者”、“編輯使用者”來給予使用者登入、部門、角色的權限。
這麼操作很順利，部門-角色-權限-使用者該有的都有的，可建立可編輯可删除，看着一切都很自由，但！是！對于權限單獨的管理不見了？往回看，角色賦權-管理權限那個界面，假如“行業”這個功能要取消了？可怎麼辦？這個時候我們就需要對權限進行管理，因而會有一個看起來很計算機的權限管理子產品。
4.權限管理
對于功能的權限管理。這兒的權限，你可以了解為這個功能是否存在平台中，這個功能有沒有區分資料範圍的。
權限管理這個子產品專業性強，僅适合對超級管理者展示，一般管理人員隻需擁有“使用者管理”、“部門管理”、“角色管理”這3個子產品。
若平台中，頁面固定，功能固定，權限管理甚至可以不存在。
好了，羅裡吧嗦的講完了。至于有沒看懂我就不理了，啊哈哈哈！
至于角色的權限繼承、角色的互斥、臨時角色、黑白名單等産品設計問題，在這個權限系統中都不存在哦，下次有機會我再來聊聊這一塊的産品設計吧~歡迎有相關設計的産品同學交流。
背景産品
權限管理
平台産品