基本常見的就是 基於RBAC
Role-based Access Control，基於角色的權限控制模型。
顧名思義，給用戶定義角色，通過角色來控制權限。目前來說基於角色權限控制模型是應用較廣的一個。特別是2B方向SAAS領域，應用尤其常見。
如上圖示，用戶擁有角色，且可擁有多個角色，而每個角色對應不同權限。
這樣的好處是：不必為每一個用戶去配置權限，擁有極大的靈活性和便利性。
1. 概念
訪問控制技術是由美國國防部（Department of Defense, DoD）資助的研究和開發成果演變而來的。這一研究導致兩種基本類型訪問控制的產生：自主訪問控制（Discretionary Access Control, DAC）和強制訪問控制（Mandatory Access Control, MAC）。最初的研究和應用主要是為了防止機密信息被未經授權者訪問，近期的應用主要是把這些策略應用到為商業領域。
自主訪問控制，允許把訪問控制權的授予和取消留給個體用戶來判斷。為沒有訪問控制權的個體用戶授予和廢除許可。自主訪問控制機制允許用戶被授權和取消訪問其控制之下的任何客體（object），換句話說，用戶就是他們控制下的客體的擁有者。對於這些組織，公司或代理機構是事實上的系統客體和處理他們的程序的擁有者。訪問優先權受組織控制，而且也常常基於雇員功能而不是數據所有權。
強制訪問控制，在美國國防部 Trusted Computer Security Evaluation Criteria (TCSEC) 中定義如下：“一種限制訪問客體的手段，它以包含在這些客體中的信息敏感性和訪問這些敏感性信息的主體的正式授權信息（如清除）為基礎”。
什么是基於角色訪問控制（Role-Based Access Control, RBAC）？NIST 有如下定義。
訪問是一種利用計算機資源去做某件事情的的能力，訪問控制是一種手段，通過它這種能力在某些情況下被允許或者受限制（通常是通過物理上和基於系統的控制）。基於計算機的訪問控制不僅可規定是“誰”或某個操作有權使用特定系統資源，而且也能規定被允許的訪問類型。這些控制方式可在計算機系統或者外部設備中實現。
就基於角色訪問控制而言，訪問決策是基於角色的，個體用戶是某個組織的一部分。用戶具有指派的角色（比如醫生、護士、出納、經理）。定義角色的過程應該基於對組織運轉的徹底分析，應該包括來自一個組織中更廣范圍用戶的輸入。
訪問權按角色名分組，資源的使用受限於授權給假定關聯角色的個體。例如，在一個醫院系統中，醫生角色可能包括進行診斷、開據處方、指示實驗室化驗等；而研究員的角色則被限制在收集用於研究的匿名臨床信息工作上。
控制訪問角色的運用可能是一種開發和加強企業特殊安全策略，進行安全管理過程流程化的有效手段。
2. 核心對象模型設計（RBAC0）
根據RBAC模型的權限設計思想，建立權限管理系統的核心對象模型.對象模型中包含的基本元素主要有：用戶（Users）、用戶組（Group）、角色（Role）、控制對象（Resource Class）、訪問模式（Access Mode）、操作（Operator）。主要的關系有：分配角色權限PA（Permission Assignment）、分配用戶角色UA（Users Assignmen描述如下：
1. 控制對象：是系統所要保護的資源（Resource Class），可以被訪問的對象。資源的定義需要注意以下兩個問題：
a) 資源具有層次關系和包含關系。例如，網頁是資源，網頁上的按鈕、文本框等對象也是資源，是網頁節點的子節點，如可以訪問按鈕，則必須能夠訪問頁面。
b) 這里提及的資源概念是指資源的類別（Resource Class），不是某個特定資源的實例（Resource Instance）。資源的類別和資源的實例的區分，以及資源的粒度的細分，有利於確定權限管理系統和應用系統之間的管理邊界，權限管理系統需要對於資源的類別進行權限管理，而應用系統需要對特定資源的實例進行權限管理。兩者的區分主要是基於以下兩點考慮：
i. 一方面，資源實例的權限常具有資源的相關性。即根據資源實例和訪問資源的主體之間的關聯關系，才可能進行資源的實例權限判斷。 例如，在管理信息系統中，需要按照營業區域划分不同部門的客戶，A區和B區都具有修改客戶資料這一受控的資源，這里“客戶檔案資料”是屬於資源的類別的范疇。如果規定A區只能修改A區管理的客戶資料，就必須要區分出資料的歸屬，這里的資源是屬於資源實例的范疇。客戶檔案（資源）本身應該有其使用者的信息（客戶資料可能就含有營業區域這一屬性），才能區分特定資源的實例操作，可以修改屬於自己管轄的信息內容。
ii. 另一方面，資源的實例權限常具有相當大的業務邏輯相關性。對不同的業務邏輯，常常意味着完全不同的權限判定原則和策略。
2. 操作（權限）：完成資源的類別和訪問策略之間的綁定。
3. 用戶：權限的擁有者或主體。用戶和權限實現分離，通過授權管理進行綁定。
4. 用戶組：一組用戶的集合。在業務邏輯的判斷中，可以實現基於個人身份或組的身份進行判斷。系統弱化了用戶組的概念，主要實現用戶（個人的身份）的方式。
5. 角色：權限分配的單位與載體。角色通過繼承關系支持分級的權限實現。例如，科長角色同時具有科長角色、科內不同業務人員角色。
6. 分配角色權限PA：實現操作和角色之間的關聯關系映射。
7. 分配用戶角色UA：實現用戶和角色之間的關聯關系映射。
3. HR數據權限模型設計初稿
3.1. 訪問主體
在本系統中訪問主體是員工和用戶組。
如圖3.1.1中每個主體都有多個角色。每個角色又可能同時屬於多個主體。
公司、部門、職位一定有對應的一個用戶組，但用戶組不一定是公司、部門、職位當中一個，也可能是虛擬出來的一個組，比如：工會組織、公司籃球隊等等。
3.2. 分配用戶角色（Users Assignmen）
如圖3.1.1這里的Users指的是所有訪問主體。用戶組、員工。
用戶組是可以無限制擴充的。
無論添加幾個主體到最后都會映射到角色（roles）表中，成為多個角色。
然后對角色分配訪問權限控制。
3.3. 操作
操作（權限）=訪問模式+資源（resource class）
如圖3.3.1，比如：頁面A有個查詢員工信息的功能，我們在這里把他看成一個“訪問客體”，被權限控制的資源（resource class）。再假設訪問模式中有個“運行”模式，那么兩者組合起來就是有個有效的操作（權限），然后把這個權限賦予角色，就OK了。
（圖3.3.1）
3.4. 分配角色權限（Permission Assignment）
3.3節中提到，根據資源和訪問模式、我們這里就有了很多操作，也就是權限。
那么我們只需要把這些權限分配到角色就可以了。如圖3.4.1
（圖3.4.1）
3.5. 資源類別（Resources Class）
根據以上的描述可以看出來，在本模型中主體是可以無限制擴充的。那么客體呢？我們可以看到，不管你有多少客體，到最后也都是分解成了多個資源類別（和主體一樣，把每個主體都分解成了多個角色），然后和訪問模式組成了操作（權限），最后賦給角色。
我們再分析下資源類別模型。
我認為我們系統的資源類別可以分為2個方向，頁面功能和流程。
比如：員工資料查詢，這個頁面上就有查詢這個客體資源類別。
而員工轉正流程中又有直接主管審批這個資源。
那么我們把資源類別（resources class）設計成如圖3.5.1
（圖3.5.1）
功能模塊表中存放“流程”或“頁面功能”。
“功能模塊類別”用來區分，這條記錄是“頁面功能”還是“流程”。
一個流程有多個審批操作。我們可以放到資源類別中。
頁面功能同理。
4. 小結
該對象模型最終將訪問控制模型轉化為訪問矩陣形式。訪問矩陣中的行對應於用戶，列對應於操作，每個矩陣元素規定了相應的角色，對應於相應的目標被准予的訪問許可、實施行為。按訪問矩陣中的行看，是訪問能力表CL(Access Capabilities)的內容；按訪問矩陣中的列看，是訪問控制表ACL（Access Control Lists）的內容。如表4.1
| 用戶 能力 |
員工1 |
員工2 |
員工3 |
員工4 |
| 查看自己部門員工通訊錄 |
部門員工 |
部門員工 |
部門員工 |
部門員工 |
| 查看自己部門員工全部資料 |
部門經理 |
|
|
|
| 查看自己公司員工通訊錄 |
部門員工 |
部門員工 |
部門員工 |
部門員工 |
| 查看自己公司員工全部資料 |
|
|
檔案管理員 |
|
（表4.1）
圖4.1為整個權限模型。
（圖4.1）
5. 思考
5.1. 相對角色
在很多時候我們都會用到相對角色這個概念。比如：員工轉正流程中就有個直接主管審批，那么這個直接主管這個角色就是一個相對角色。這個相對角色在數據庫權限模型中其實也是一個角色，只用添加到角色表中給這個角色賦權限（操作）就可以了，但在開發過程中一定要注意相對角色的設定，特別是設定方法，公式。
5.2. 用戶組的聯想
用戶組可以是組織架構中的實體單位。同時也可以是虛擬的，由用戶自己添加、配置的一個角色的集合。角色又是權限的集合。
那么我們可以這么做，添加一個系統管理員組，然后通過角色為這個組，分配好應有的權限。以后如果有新的系統管理員，我們只需要放到這個組里面去就可以，沒必要再重新配置一個用戶。
這樣就完全可以實現windows的權限管理了。
5.3. 角色的繼承
給角色分配權限（操作）其實也是件比較復雜的工作。如果角色間存在一定的關系，可以直接把另外一個角色的權限直接復制過來，然后再添加自己需要的其他權限，這樣不是會方便很多嗎？
繼承可分為兩種方式，一般繼承關系和受限繼承關系。一般繼承關系僅要求角色繼承關系是一個絕對偏序關系（不能繼承自己的子類），允許角色間的多繼承。而受限繼承關系則進一步要求角色繼承關系是一個樹結構（單繼承）。
5.4. 資源實例（Resource Instance）
場景1：有一個功能頁面，查詢員工資料。可訪問角色有“人事專員”和“部門經理”。“人事專員”進入可以查出全公司的所有員工資料。“部門經理”進入后，只能查出自己部門的員工資料。
場景1的解決方案：
1. 在功能模塊（functionmodule）表中添加“查詢員工資料”這個功能。
2. 在功能資源（functionresource）表中添加這個“查詢員工資料”的兩個資源，“部門經理查詢”和“人事專員查詢”。
3. 抽象成資源類別（resourcesclass）。
4. 資源類別（resourcesclass）和訪問模式（accessmode）組合成2個操作（權限）。
5. 把這兩個權限分別賦予部門經理組所擁有的角色和人事專員組所擁有的角色。
6. 在開發過程中就可以根據兩個不同的資源，在這個頁面做查詢條件的處理。
場景2：有一個功能頁面，部門花名冊。可訪問角色有“部門經理”和任何登錄后的員工。根據員工部門自動顯示所在部門的花名冊。如果是“部門經理”，就顯示一些“部門經理”可以看到的敏感信息。比如，工資。
場景2的解決方案：
1. 在功能模塊（functionmodule）表中添加“部門花名冊”這個功能。
2. 在功能資源（functionresource）表中添加這個“部門花名冊”的一個資源，“部門經理花名冊”。
3. 抽象成資源類別（resourcesclass）。
4. 資源類別（resourcesclass）和訪問模式（accessmode）組合成1個操作（權限）。
5. 把這個權限賦予部門經理組所擁有的角色。
6. 在開發過程中進入這個功能頁面，沒有這個權限的顯示一般花名冊。有這個權限的顯示部門經理花名冊。
小結：
資源實例讓我們在按鈕級權限的基礎上，加上了對記錄和字段的控制。當然，你也可以把場景1和場景2結合起來。記錄、字段一起控制，這個肯定是可以的。
再擴展下。場景二中，如果有一天部門經理所能看到的東西改變了，加一項或少一項，怎么辦呢？難道去改代碼？
其實在很多情況下，都是可以做死的。比如場景二中大家都只能看到自己部門的花名冊。肯定不會有一天要看公司的花名冊，如果真有這個需求，那么就應該再做個功能頁面。叫做“公司花名冊”。
但也有些情況，是要可以調整的。同樣是場景二，部門經理能看到的東西。哪天公司想變變，這個也是有可能的。
其實這個功能實現起來也非常簡單。如圖5.4.1。
無論什么，到最后都會變成資源類別，我們直接給這個類別記錄一些屬性。到時候你只要根據這些屬性顯示就可以了，要變的時候把這些屬性變了就行了。只要願意，完全可以做個維護頁面。
表資源設置（resourcesetting）記錄一些訪問條件。比如，這個資源按部門查詢。如果需要你可以把他改成按公司查詢。
表字段設置（fieldsetting）記錄的是這個資源的字段信息。比如，部門經理可以看到“部門花名冊”的字段。
（圖5.4.1）
6. 總結
本模型的主要設計思想是把所有訪問主體，包括部門、職位、公司、人等等。全部分解成一個或多個角色。
把所有訪問控制客體全部分解成一個和多個資源類別（Resources Class）。
把資源類別加上訪問模式（讀、寫、刪、運行等）成為一個操作，也就是權限。
然后把這個權限賦予到角色。
這個模型支持頁面級權限、按鈕級權限、記錄級權限、字段級權限和這幾種權限的任意組合。
在角色的分配上。他本身是支持一個客體有多個角色，一個角色屬於多個客體。支持用戶組角色、角色繼承、相對角色等。特別是用戶組這個設計。部門、職位、公司這些組織都可以抽象成一個用戶組，直接給這個組分配權限就可以了。但用戶組不僅僅只有抽象實體組織這功能，他還可以無限制的擴展。比如可以添加一個虛擬的系統管理員組。他本身就是一個員工的集合，你可以以任何形式去組合人員
在互聯網產品中，海量用戶的背后，產品所服務的用戶角色往往並不是單一的。在交互設計日常的實際項目中，經常會遇到由於用戶角色差異而產生的多權限模型設計。所謂多用戶角色模型，是指單一的內容整體在不同場景，不同對象權限下的不同展示形式。在某些情況下，單一的內容整體會隨着對象權限的差異性進行頁面交互形態的再設計。
在產品應用中，模塊化的頁面形態和內容所要呈現的目標用戶並不是單一的，而是會隨着用戶屬性的不同發生着變化，作為交互設計師的項目日常，同一個產品中的同一個模塊，為多類用戶設計的需求場景不在少數。這一類的需求場景相對於單一用戶角色的項目而言，需要從更多維度去了解每種用戶角色的需求利益點，從而在不同的用戶角色和不同的權限條件下提供差異性&協作性的產品服務。
總結一下，日常項目中經常遇到的多權限場景主要可以分為以下幾種類型：
- 大量權限：“千人千面”，利用大數據進行頁面的個性化設計呈現；
- 雙權限（三權限）：模塊平台連接兩類相互作用的用戶對象，常見於O2O等應用場景；
- 多權限：線性信息流，常見於To B端的業務信息流。
1. 大量用戶權限：“千人千面”，利用大數據進行頁面的個性化設計呈現
該種應用場景最多的是大型電商產品的首頁，海量的商品SKU和用戶UV，用戶屬性的千差萬別，“千人一面”的界面已經很難滿足用戶的個性化需求，高效而精准地鏈接不同用戶的需求和商品推薦成了“千人千面”地進行用戶極度權限細分所扮演的重要角色。
那前期從用戶自身的行為數據出發，用戶側如何獲取個性化的權限，進而被系統推薦個性化的頁面運營策略，設計的基本流程如下：這類用戶權限的獲取是基於用戶多維屬性標簽形成的特定身份角色。
在大數據的背景下，用戶權限的無限細分會對產品設計開發的工作量形成挑戰。在“千人千面”用戶細分的下游，衍生出了諸如“魯班”類的個性化設計呈現工具，基於海量的數據，用戶的權限可以被細分到驚人的程度，由此帶來的是個性化設計工作量的井噴增長。高效的AI設計工具正是迎合了由用戶權限的無限細分帶來的設計工作量井噴式增長的需求。 2016 年，魯班首次服務雙 11，制作了 1.7 億張商品banner。2017 年雙 11 有 4 億張人工智能海報由AI設計完成。如果全靠設計師人手來完成，假設每張圖需要耗時 20 分鍾，滿打滿算需要 100 個設計師連續做 300 年。如此高效率的AI設計工具為用戶權限（角色）的無限細分創造了可能。
2. 雙權限：模塊平台連接兩類相互作用的用戶對象，常見於O2O等應用場景
這類用戶權限是基於用戶在產品服務中的角色定位，在有些產品場景中可能會有三權限的情況，但雙權限仍然適用於大多數情況。
這一類型的多權限內容模塊多應用於關聯兩種相互作用的用戶對象中，用戶A和用戶B同為產品的服務對象，在用戶角色需求上，既互相關聯，又存在差異。在設計前期需要分別分析他們各自的需求利益點，相同的做合並處理，拆分具有差異性的，繼而在設計上滿足不同角色用戶對於產品服務的差異性需求。常見的產品場景中互相關聯的用戶角色關系：
對於這一類的應用場景，遵循一般的設計流程：
- 明確模塊的基本功能目標；
- 對於用戶A和用戶B的共同需求保持通用；
- 對用戶A和用戶B的差異性需求做出分析。
以順風車應用場景為例，在順風車產品中平台服務車主和乘客雙方，那么在某些涉及車主和乘客相互協作的模塊信息時，可以對標上述設計流程具體來看，如下：
（1）明確模塊的基本功能目標
乘客和司機的角色是相互作用的，兩種角色各自的任務信息流如下圖所示，為了便於說明，在此取其中的 待出發信息詳情（主要是指乘客在被司機接單——上車，而司機是在接到乘客需求——接到乘客這期間，姑且將其稱為 待出發信息詳情）信息流進行分析。
待出發詳情模塊主要功能是為了向應用的服務各方提供出發前狀態的基本信息。
（2）對各用戶角色所對應的信息流進行需求分析
在待出發信息詳情模塊中，乘客和司機的主要需求點。
作為乘客，主要的需求點在於：
- 事先與司機約定的上車時間、地點，提醒自己及時赴約。
- 獲知司機的主要信息（電話等聯系方式、IM溝通組件、當前行駛路線）以便於及時的與司機溝通上車前事宜。
- 導航、取消訂單等其他操作需求
作為司機，主要的需求點在於：
- 乘客的上車時間、地點；提醒自己及時去接乘客。
- 乘客的主要信息（電話等聯系方式、IM溝通組件）；以便於及時的與其溝通上車前事宜。
- 導航、取消訂單等其他操作需求
- 拼其他乘客；作為順風車司機，乘客拼車數量最大化能使車主拼車收益最大化，也符合順風車低碳、環保、提高用戶出行效率的產品定位。
- 開始行程；司機作為拼車收益獲得方，應由其記錄行程。
（3）對各用戶角色分析得到的需求利益點進行合並和拆分處理
有效地分析了各種用戶角色的需求關系，並對其中的各需求點進行有效地合並和拆分，並在此基礎上確定產品的設計目標。
3. 多權限：線性信息流，常見於To B端的業務信息流
在To B在線協作流程中，用戶角色所對應權限的概念被提升到更高的層面。在該場景中，用戶權限既不是基於用戶自身的標簽屬性，也不是基於用戶自身的角色定位，而是基於用戶在To B協作中的組織職能。且該權限關系往往對標線下組織架構的實際職能關系。對於這一類的多用戶角色模型的設計流程，大致可以分成以下2個階段：
（1）明確組織的職能架構
一個龐雜的To B 系統中，往往包含若干條多線並行的信息流。常用的如：報銷、請假、權限使用、移動審批等。在設計相關需求時，需要首先明確該需求對應信息流的組織職能架構。舉例說明，在同一個To B 系統中，報銷流程和請假流程對應信息流所涉及的職能崗位很大程度上是不一致的。因此在設計之前首先應該梳理目標設計流程所對應的職能架構。
（2）分別對標各職能崗位節點的權限信息
以傳統OA報銷審批為例，在1)中首先明確了OA報銷審批對應的職能信息流，接下來按照各職能崗位的節點來梳理對應的權限需求點。
4. 小結
在海量的移動應用中，同時為多類用戶角色服務的產品場景非常多，以上只是基於日常工作列舉的三種常見形式。在針對這些場景中的需求設計時，往往不能單一維度地去思考用戶的需求點，需要將各種用戶角色之間的需求點按照時間&場景的維度去連接，才能保證產品的易用性和平台協作的高效性。
原文鏈接：https://www.cnblogs.com/ttcre2/archive/2008/07/24/1250591.html
http://www.woshipm.com/pd/2174816.html
http://www.woshipm.com/ucd/1036860.html
https://www.cnblogs.com/skypurple/archive/2010/10/08/1845764.html