權限管理，這是每個軟件系統都會涉及到的，而且權限管理的需求本質往往都是一樣，無在乎怎麼的角色擁有怎樣的權限，只要你充當了這個角色，你就擁有了這些功能。
舉個簡單例子：一個老師在學校教室她就擁有教書育人的權利義務，一個丈夫在家就有呵護妻子支撐家庭的權利義務，而一個父親在孩子面前就有保護孩子，教育孩子的權利義務……而作爲一個男生，我們很可能在不同的場所，成爲這些角色，從而擁有了這些權利義務。而抽象出來就是用戶，角色和權利三個方面。
所以經過前人對權限方面的總結抽象，總結出來RBAC（Role-Based Access Control ）基於角色的訪問控制。在以前做項目的時候，就聽組長說權限管理模型的運用，但是自己但是隻是接觸了一下，直到後來在項目中真正的使用，纔對此有深刻的理解。
RBAC認爲授權實際就是who,what,how三者之間的關係，即who對what進行how的操作。Who,權限的擁用者或主體（如Principal、User、Group、Role、Actor等等）；what,權限針對的對象或資源（Resource、Class） ；How,具體的權限（Privilege,正向授權與負向授權）。簡單一點說吧就是，我們通過給角色授權，然後將附有權利的角色施加到某個用戶身上，這樣用戶就可以實施相應的權利了。通過中間角色的身份，是權限管理更加靈活：角色的權利可以靈活改變，用戶的角色的身份可以隨着場所的不同而發生改變等。這樣這套RBAC就幾乎可以運用到所有的權限管理的模塊上了。
好，看一下RBAC的分類吧：
1，核心RABC0：這是權限管理的核心部分，其他的版本都是建立在0的基礎上的，看一下類圖：
通常情況下，RBAC0模型就可以解決權限模型，是最通用的。圖中描述了，1，用戶和角色是多對多的關係，表示一個用戶在不同的場景下可以擁有不同的角色，例如項目經理也可以是項目架構師等；當然了一個角色可以給多個用戶，例如一個項目中有多個組長，多個組員等。這裏需要提出的是，將用戶和許可進行分離，是彼此相互獨立，使權限的授權認證更加靈活。2，角色和許可（權限）是多對多的關係，表示角色可以擁有多分權利，同一個權利可以授給多個角色都是非常容易理解的，想想現實生活中，當官的級別不同的權限的情景，其實這個模型就是對權限這方面的一個抽象，聯繫生活理解就非常容易了。
在項目中開發中我們正是使用這種最簡單，但是卻最通用的權限模型。這裏想提一下我們建數據庫表，我們用了五張表來實現這個權限模型，將其中的兩個多對多分解成了兩對多對一來完成，這樣更有利於我們維護表，感覺也更加簡單，更容易控制。看下邊看一下我們表的設計吧:
這樣,我們項目中就用五張表來進行權限方面的管理了,在用戶表中保存用戶,角色表中保存角色級別,許可表中保存各種權限信息,然後通過中間表,來維護彼此之間的關係。這樣就完成了權限的管理了。
2，RBAC1，基於RBAC0模型，進行了角色的分層，也就是說角色上有了上下級的區別，存在了繼承包含關係，也就是前邊說過的適合於用樹展現的哪種自關聯的結構，這種模型合適於角色之間的層次明確，包含明確。但是認爲用第一種模型也是可以的，只不過第一種可能會有數據冗餘，沒有這種更加面向對象化而已。
3，RBAC2，也是基於RBAC0模型的基礎上，進行了角色的訪問控制。a,RBAC2中的一個基本限制時互斥角色的限制，互斥角色是指各自權限互相制約的兩個角色。對於這類角色一個用戶在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色；b,是指角色的權利權利是有限的，用戶有用的角色也是有限的，當然分配用戶時也是有限的，不能進行無限制的分配用戶，例如公司的領導人有限的；c,是指要想獲得較高的權限，要首先擁有低一級的權限。就像我們生活中，國家主席是從副主席中選舉的一樣。看一下它的類圖吧：
4，RBAC3，也就是最全面級的權限管理，它是基於RBAC0的基礎上，將RBAC1和RBAC2進行整合了，最前面，也最複雜的：
綜上爲權限管理模型的相關介紹，其實在任何系統中都會涉及到權限管理的模塊，無論複雜簡單，我們都可以通過以RBAC模型爲基礎，進行相關靈活運用來解決我們的問題。