這篇文章講解了liferay中使用的權限管理系統的內部細節，涉及到數據庫表以及實體之間的管理和權限管理的邏輯。
下面的ERD圖（實體關圖）展現了所有涉及到的實體關係：
主要實體
首先從表或者本人更喜歡稱作實體的表開始，換言之，他們界定的實體定義了關於權限和角色的東東。
User_：用戶
最明顯主要的一個實體就是“用戶”（Users）了。關於權限的一個總是被提及的問題是："Does this user have permission to do this action on this thing?" ，用戶就是執行某些操作完成某些任務的人。
Organization_：組織
用戶只能夠屬於一個組織（Organization）或一個地區（Location）。這裏使用了一個相同的數據模型表示Organzation和Location。基本上如果
列parentOrganizationId的值是-1，則表示一個Organization，否則就是一個Location。在邏輯上一個Location的父必須是一個Organization。
用戶（Users）能夠繼承所屬Organization或Location的權限（permissions/roles）
UserGroup:用戶組
用戶可以屬於一個或多個的用戶組，用戶組僅僅是一堆用戶的集合，不屬於任何公司、任何組織、任何地區，僅僅只是爲了方便分配角色或權限，而將具有
共性（比如：具有相同的崗位或職務等）的一些用戶進行分組。，用戶能夠從用戶組繼承權限（permissions/roles）。當前
parentUserGroupId列未使用。
Group_:組
組Group）現在稱作社區（Communities），用戶可以屬於一個或多個的社區，並且能夠集成所屬社區的權限和角色。注意在Group_
表中，存在一個className和classPk列。如果某條記錄的這兩個列的值爲空，則該條記錄指的是一個社區。如果className的值是
com.liferay.portal.model.User，則該條記錄爲一個私有的用戶社區（只允許Power
Users）.如果className 的值是
com.liferay.portal.model.Organization，則這條記錄表示了一個組織（Organization）或地區
（Location）如果className 的值是
com.liferay.portal.model.UserGroup則表示這條記錄記錄的是一個UserGroup（用戶組）。可以說：組
（Group）是Organization和Location已經UserGroup的集合。
存在組（Group）用於記錄Organizations/Locations 和UserGroups的原因在於：這樣可以簡化其他實體（比如權限（permissions）和角色（role））同用戶（Users）之間的關係。
權限和角色（Permissions and Roles）
好，現在讓我們看看這些表是怎樣和權限關聯起來的，首先我們要看一下“權限”（permission）是如何定義的，簡單地說，權限就是在資源
（RESOURCE）上的操作（ACTION）。權限能夠被直接授予用戶（USER）或通過不同的方式被繼承。角色是權限的集合。讓我們從
“Resource_”表開始
Resource_ 表:
Resource_
一個資源可以是在prtal中代表一個對象的，你要在上施加權限的任何東西。可以是一個portlet，一個社區（community），一個用戶
（User），一個消息公告,一個Blog實體...任何都可以。讓我們先快速瀏覽一下Resource_表格的各個列：
* resourceId = 資源的標識
* companyId = 資源所屬的公司ID
* name = 資源對象的描述，如果資源描述的是一個portlet對象，則爲這個portlet對象的portletId.如果是一個class, 則爲帶包名的class全名稱。
* typeId = 在當前，只是用來描述classes的權限，因此該列的值總是"class". 然而,在將來, 也許回用來描述files或folders授權,因此 typeId 的值可能會是 "file" or "folder".
* scope = 這裏可能的值是"company" (指 企業級"Enterprise Scope"), "group"
(指 社區級"Community Scope"), or "individual" (指私人級"Individual Scope"). Why
the different naming conventions? Because things change... The numeric
values for scope (as found in the database) can be found in the class
com.liferay.portal.model.impl.ResourceImpl
Permission_ 表
如前所述，權限（permission）是在資源上施加的操作，因此Permission_表有actionId和resourceId這兩個
列，像預料的一樣，這裏的resourceId列引用Resource_表的resourceId列。然而，actionId列不存在對應的
Action_表，所有的actionId定義在ActionKeys類中。如何在資源上定義一個新的操作？可以閱讀權限的實現代碼。
Role_ 表，這個表定義了角色，實際上，這裏只有一個主要的列是“name”，這是因爲角色（roles）必須有一個獨一無二的名稱。
Roles_Permissions 角色-權限表
這是連接權限和角色的關係表，沒有這裏的連接，角色就沒有用了...他們僅是一下空的容器。
分配用戶到社區和組織（communities and organizations）
Users_Groups 表：是用戶（User）和社區（Community）的關係表。你也許感到困惑，爲什莫這裏沒有className和classPK列在這張表中，
這樣的話我們就能夠處理所有的實體（例如社區Communites, 組織Organization/地區Locations,
用戶組UserGroups）。這很難解釋...(原文就是這樣：...too hard to explain, but trust
us...it's better this way.)
Users_Orgs 用戶-組織表
連接用戶 User 到一個組織（Organization）/地區（Location.）的關係表
Users_UserGroups
連接用戶 User 到一個用戶組（UserGroup）的關係表
分配角色和權限
Users_Permissions 用戶-權限 表
直接連接一個權限（Permission）到用戶（User）的關係表.
Users_Roles 用戶-角色 表
連接角色（Role）到用戶（User）的關係表，用戶有所屬角色的所有權限（通過Roles_Permissions）
Groups_Permissions 組-權限 表
連接一個權限permission 到一個組
Group的關係表.還記得在前面提到過，一個Group_記錄能夠表示社區（Community），組織（Organization）/地區
（Location）或是用戶組（UserGroup）嗎？好，通過這個表可以之間關聯到所有這些實體，當然屬於這些實體的用戶能夠繼承他們的權限，需要
注意的是，沒有Orgs_Permissions 或 UserGroups_Permissions
表。Groups_Permissions足夠處理這些事情，因此纔是現在看起來比較簡單
Groups_Roles 組-角色 表
連接角色（role）到組（Group）的關係表，像Groups_Permissions一樣，組（Group）可以是社區、組織/地區或用戶組（UserGroup）,用戶能夠繼承這些“組（Group）”對應的角色權限。
Groups_Orgs 組-組織 表
是連接組織（Organization）/地區（Location）的關係表，換言之，一個管理員（admin）能夠分配任何組織或地區的所屬用戶到一個社區。
結果是：分配給社區的任何權限或角色能夠被在組織或地區中選擇的用戶繼承。
Groups_UserGroups 組-用戶組
實際上像Groups_Orgs一樣。只是針對UserGroup而已。
OrgGroupPermission 這個表在代碼沒有被使用到，實際上被用作“排除權限”，基本上來說，一個用戶必須屬於一個特定的地區（或組織，從liferay4.4開始）和一個特定的社區（Community）。雖然該表存在，但是在代碼中並沒有使用。
可以通過一個例子瞭解爲什麼這個選項是有用的，在一個社區（Community）中假設有一個留言板，管理員想要設置某一類的留言板能夠給地區
（Location）的用戶留言，一次他點擊“Permission”圖標，選取了特定的地區（Location），現在所有的屬於這個Location
的用戶都能夠留言了，而不管他們是否屬於這個社區。
在另外的場景下，管理員想要進行更多的限制，用戶必須屬於指定的組織才能發表留言，他就可以通過設置“排除權限”來完成。
==================================================================
當前的Liferay權限結構是從4.0版本開始的。jsr168中基於role的權限設計只解決了開發技術層面，並沒有和實際的應用關聯起來。在Liferay中權限設計有很大的擴展，並可在多個層次進行配置。
首先要解釋的是Liferay的權限模型。首先看一下Liferay的定義
A permission is defined as an action acting on a resource
在Liferay中，權限作用是判斷當前用戶是否允許在Resource上進行某項操作(action)。
Resource代表着一個個的可操作的實體。在Portal系統中，最直觀的Resource就是一個個的Portlet。但是由於應用的原
因，在Portlet下還可以根據應用的功能再細分，最典型的就是Message Board
Portlet下還分Category和Message兩類Resource。這些Resource是很直觀的。此外還存在一些特殊的Resource可
以控制，比如每張Page也是Resource。另外由於在Liferay中可以配置多個Community，每個Community都可以多次放置同一
種Portlet作爲多個Instance的，所以對於Resource又附加了Scope的概念。Resource有三種
Scope：Enterprise、Community和Individual。Enterprise代表整個Portal系統中的一類資
源，Community需要指明是哪個Community下的一類資源，Individual則是獨立的Resource。
舉個例子，我們要定義一個Permission
View＋Message Board Topic / Enterprise
上面的定義說明，“查看當前Portal系統中任一個Message Board的Topic”。
再舉個例子
Update Message Board Topic / "Developer" Community Scope
上面的定義說明，“修改 Developer 這個 Community 下的任一個 Message Board Topic ”。
在Liferay Portal中所有Portlet都會有默認的View/Configuration
Action。其他的Resource和Action都需要開發人員預先設計，並在代碼中調用PermissionChecker檢驗當前用戶是否擁有權
限。這是後話，今後在開發相關的文章中再討論。
如果理解了上面關於Resource、Scope和Action，接下去我們就可以討論Liferay中如何進行設置，將Permission和User聯繫起來從而將權限賦予某人。
首先說最簡單的Individual類型的Resource的配置方法。如果以管理員身份登錄系統，那麼在任何一個portlet的右上角都有一個齒輪圖標，點擊該圖標後選擇Permissions標籤就可進行該portlet得配置。
假設我們以管理員身份登錄後切換到support Community，對Message Boards權限進行配置。
新出現的頁面第一排中如果選擇Users、Organizations、Locations、User Groups，下方還將出現Current和Available。
