許可權管理，這是每個軟體系統都會涉及到的，而且許可權管理的需求本質往往都是一樣，無在乎怎麼的角色擁有怎樣的許可權，只要你充當了這個角色，你就擁有了這些功能。

舉個簡單例子：一個老師在學校教室她就擁有教書育人的權利義務，一個丈夫在家就有呵護妻子支撐家庭的權利義務，而一個父親在孩子面前就有保護孩子，教育孩子的權利義務……而作為一個男生，我們很可能在不同的場所，成為這些角色，從而擁有了這些權利義務。而抽象出來就是使用者，角色和權利三個方面。

所以經過前人對許可權方面的總結抽象，總結出來RBAC（Role-Based Access Control ）基於角色的訪問控制。在以前做專案的時候，就聽組長說許可權管理模型的運用，但是自己但是隻是接觸了一下，直到後來在專案中真正的使用，才對此有深刻的理解。

           RBAC認為授權實際就是who,what,how三者之間的關係，即who對what進行how的操作。Who,許可權的擁用者或主體（如Principal、User、Group、Role、Actor等等）；what,許可權針對的物件或資源（Resource、Class） ；How,具體的許可權（Privilege,正向授權與負向授權）。簡單一點說吧就是，我們通過給角色授權，然後將附有權利的角色施加到某個使用者身上，這樣使用者就可以實施相應的權利了。通過中間角色的身份，是許可權管理更加靈活：角色的權利可以靈活改變，使用者的角色的身份可以隨著場所的不同而發生改變等。這樣這套

好，看一下RBAC的分類吧：

        1，核心RABC0：這是許可權管理的核心部分，其他的版本都是建立在0的基礎上的，看一下類圖：

通常情況下，RBAC0模型就可以解決許可權模型，是最通用的。圖中描述了，1，使用者和角色是多對多的關係，表示一個使用者在不同的場景下可以擁有不同的角色，例如專案經理也可以是專案架構師等；當然了一個角色可以給多個使用者，例如一個專案中有多個組長，多個組員等。這裡需要提出的是，將使用者和許可進行分離，是彼此相互獨立，使許可權的授權認證更加靈活。2，角色和許可（許可權）是多對多的關係，表示角色可以擁有多分權利，同一個權利可以授給多個角色都是非常容易理解的，想想現實生活中，當官的級別不同的許可權的情景，其實這個模型就是對許可權這方面的一個抽象，聯絡生活理解就非常容易了。

在專案中開發中我們正是使用這種最簡單，但是卻最通用的許可權模型。這裡想提一下我們建資料庫表，我們用了五張表來實現這個許可權模型，將其中的兩個多對多分解成了兩對多對一來完成，這樣更有利於我們維護表，感覺也更加簡單，更容易控制。看下邊看一下我們表的設計吧:

這樣,我們專案中就用五張表來進行許可權方面的管理了,在使用者表中儲存使用者,角色表中儲存角色級別,許可表中儲存各種許可權資訊,然後通過中間表,來維護彼此之間的關係。這樣就完成了許可權的管理了。

        2，RBAC1，基於RBAC0模型，進行了角色的分層，也就是說角色上有了上下級的區別，存在了繼承包含關係，也就是前邊說過的適合於用樹展現的哪種自關聯的結構，這種模型合適於角色之間的層次明確，包含明確。但是認為用第一種模型也是可以的，只不過第一種可能會有資料冗餘，沒有這種更加面向物件化而已。

          3，RBAC2，也是基於RBAC0模型的基礎上，進行了角色的訪問控制。a,RBAC2中的一個基本限制時互斥角色的限制，互斥角色是指各自許可權互相制約的兩個角色。對於這類角色一個使用者在某一次活動中只能被分配其中的一個角色，不能同時獲得兩個角色的使用權。常舉的例子：在審計活動中，一個角色不能同時被指派給會計角色和審計員角色；b,是指角色的權利權利是有限的，使用者有用的角色也是有限的，當然分配使用者時也是有限的，不能進行無限制的分配使用者，例如公司的領導人有限的；c,是指要想獲得較高的許可權，要首先擁有低一級的許可權。就像我們生活中，國家主席是從副主席中選舉的一樣。看一下它的類圖吧：

          4，RBAC3，也就是最全面級的許可權管理，它是基於RBAC0的基礎上，將RBAC1和RBAC2進行整合了，最前面，也最複雜的：

綜上為許可權管理模型的相關介紹，其實在任何系統中都會涉及到許可權管理的模組，無論複雜簡單，我們都可以通過以RBAC模型為基礎，進行相關靈活運用來解決我們的問題。