這篇文章講解了liferay中使用的權限管理系統的內部細節，涉及到數據庫表以及實體之間的管理和權限管理的邏輯。
下面的ERD圖（實體關圖）展現了所有涉及到的實體關係：
下面的ERD圖（實體關圖）展現了所有涉及到的實體關係：
主要實體
首先從表或者本人更喜歡稱作實體的表開始，換言之，他們界定的實體定義了關於權限和角色的東東。
User_：用戶
最明顯主要的一個實體就是“用戶”（Users）了。關於權限的一個總是被提及的問題是："Does this user have permission to do this action on this thing?" ，用戶就是執行某些操作完成某些任務的人。
首先從表或者本人更喜歡稱作實體的表開始，換言之，他們界定的實體定義了關於權限和角色的東東。
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）
用戶只能夠屬於一個組織（Organization）或一個地區（Location）。這裏使用了一個相同的數據模型表示Organzation和Location。基本上如果
列parentOrganizationId的值是-1，則表示一個Organization，否則就是一個Location。在邏輯上一個Location的父必須是一個Organization。
用戶（Users）能夠繼承所屬Organization或Location的權限（permissions/roles）
UserGroup:用戶組
用戶可以屬於一個或多個的用戶組，用戶組僅僅是一堆用戶的集合，不屬於任何公司、任何組織、任何地區，僅僅只是爲了方便分配角色或權限，而將具有共性（比如：具有相同的崗位或職務等）的一些用戶進行分組。，用戶能夠從用戶組繼承權限（permissions/roles）。當前parentUserGroupId列未使用。
用戶可以屬於一個或多個的用戶組，用戶組僅僅是一堆用戶的集合，不屬於任何公司、任何組織、任何地區，僅僅只是爲了方便分配角色或權限，而將具有共性（比如：具有相同的崗位或職務等）的一些用戶進行分組。，用戶能夠從用戶組繼承權限（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）之間的關係。
組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）是如何定義的，簡單地說，權限就是在資源（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類中。如何在資源上定義一個新的操作？可以閱讀權限的實現代碼。
如前所述，權限（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_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）的關係表
連接用戶 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而已。
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的用戶都能夠留言了，而不管他們是否屬於這個社區。
在另外的場景下，管理員想要進行更多的限制，用戶必須屬於指定的組織才能發表留言，他就可以通過設置“排除權限”來完成。
可以通過一個例子瞭解爲什麼這個選項是有用的，在一個社區（Community）中假設有一個留言板，管理員想要設置某一類的留言板能夠給地區（Location）的用戶留言，一次他點擊“Permission”圖標，選取了特定的地區（Location），現在所有的屬於這個Location的用戶都能夠留言了，而不管他們是否屬於這個社區。
在另外的場景下，管理員想要進行更多的限制，用戶必須屬於指定的組織才能發表留言，他就可以通過設置“排除權限”來完成。