Liferay权限管理的讲解

这篇文章讲解了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。