經常整理、反思，才能進步。——一位偉大的哲學家還原真相：
事情是這樣的，我在實習的時候，我的實習導師安排我做系統後台管理中的「使用者資訊管理」、「角色管理」、「許可權管理」三個進行分析，並讓我說了說我的想法。初生牛犢不怕虎，稍微思索了下，就開始講。在講到角色管理和許可權管理的時候，我就說可以將角色管理和許可權管理合併，直接單獨對使用者進行賦予權力。概念：事實上這樣子也是沒錯的，畢竟我在後面在blog上查詢資料的時候，我發現其實很多系統並沒有將這個功能進行如此的細緻化。想著是央企，這麼做應該有自己的道理。導師肯定了我的想法，但還是要我去查下資料，了解下「角色和使用者的關係」，我意識到我可能出了問題了。
who：許可權的擁用者或主體（principal(負責人)、user、group、role、actor等等）
what：許可權針對的物件或資源（resource、class）。
how：具體的許可權（privilege, 正向授權與負向授權）。
role：是角色，擁有一定數量的許可權。
operator：操作。表明對what的how 操作。
解釋：
user：與 role 相關，使用者僅僅是純粹的使用者，許可權是被分離出去了的。user是不能與 privilege 直接相關的，user 要擁有對某種資源的許可權，必須通過role去關聯。解決 who 的問題。
resource：就是系統的資源，比如部門新聞，文件等各種可以被提供給使用者訪問的物件。
privilege：是resource related的許可權。就是指，這個許可權是繫結在特定的資源例項上的。比如說部門新聞的發布許可權，叫做」部門新聞發布許可權」。這就表明，該privilege是乙個發布許可權，而且是針對部門新聞這種資源的一種發布許可權。privilege是由creator在做開發時就確定的。privilege 如」刪除」 是乙個抽象的名詞，當它不與任何具體的 object 或 resource 繫結在一起時是沒有任何意義的。拿新聞發布來說，發布是一種許可權，但是只說發布它是毫無意義的。因為不知道發布可以操作的物件是什麼。只有當發布與新聞結合在一起時，才會產生真正的 privilege。這就是 privilege instance。
role：是粗粒度和細粒度(業務邏輯)的介面，乙個基於粗粒度控制的許可權框架軟體，對外的介面應該是role，具體業務實現可以直接繼承或拓展豐富role的內容，role不是如同user或group的具體實體，它是介面概念，抽象的通稱。
operator的定義包括了resource type和method概念。即，what和how的概念。之所以將what和how繫結在一起作為乙個operator概念而不是分開建模再建立關聯，這是因為很多的how對於某what才有意義。比如，發布操作對新聞物件才有意義，對使用者物件則沒有意義。 。
使用者 角色 許可權
最近因為要用到許可權這個東西，感覺腦袋很是有點亂，昨天硬是搞到大半夜才終於理清了思路。現在我就將我的思路和大家分享一下，不敢保證完全正確，大家看看便罷。看看便罷 一般我們使用到 使用者 角色 許可權 這三張表的時候，會發現表裡會有很多字段，然後相對應的外來鍵也是很多，往往我們就容易混亂。現在我這邊列...
使用者角色許可權
rbac role based access control，基於角色的訪問控制 就是使用者通過角色與許可權進行關聯。簡單地說，乙個使用者擁有若干角色，每乙個角色擁有若干許可權。這樣，就構造成 使用者 角色 許可權 的授權模型。在這種模型中，使用者與角色之間，角色與許可權之間，一般者是多對多的關係。...
使用者角色許可權
1 使用者表 sys user idorg id login name password user name phone email create time login time 主鍵id 組織id 使用者登陸名 使用者密碼 使用者姓名 手機號電子郵箱 建立時間 登陸時間 2 角色表 sys rol...