liferay权限结构.docx
《liferay权限结构.docx》由会员分享，可在线阅读，更多相关《liferay权限结构.docx（16页珍藏版）》请在冰点文库上搜索。
liferay权限结构
Liferay权限管理的讲解
这篇文章讲解了liferay中使用的权限管理系统的内部细节，涉及到数据库表以及实体之间的管理和权限管理的逻辑。
下面的ERD图（实体关图）展现了所有涉及到的实体关系
主要实体
首先从表或者本人更喜欢称作实体的表开始，换言之，他们界定的实体定义了关于权限和角色的东东。
User_：
用户
最明显主要的一个实体就是“用户”（Users）了。
关于权限的一个总是被提及的问题是：
"Doesthisuserhavepermissiontodothisactiononthisthing?
"，用户就是执行某些操作完成某些任务的人。
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，则该条记录为一个私有的用户社区（只允许PowerUsers）.如果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）之间的关系。
权限和角色（PermissionsandRoles）
好，现在让我们看看这些表是怎样和权限关联起来的，首先我们要看一下“权限”（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"（指企业级"EnterpriseScope"）,"group"（指社区级"CommunityScope"）,or"individual"（指私人级"IndividualScope"）.Whythedifferentnamingconventions?
Becausethingschange...Thenumericvaluesforscope（asfoundinthedatabase）canbefoundintheclasscom.liferay.portal.model.impl.ResourceImpl
Permission_表
如前所述，权限（permission）是在资源上施加的操作，因此Permission_表有actionId和resourceId这两个列，像预料的一样，这里的resourceId列引用Resource_表的resourceId列。
然而，actionId列不存在对应的Action_表，所有的actionId定义在ActionKeys类中。
如何在资源上定义一个新的操作？
可以阅读权限的实现代码。
Role_表，这个表定义了角色，实际上，这里只有一个主要的列是“name”，这是因为角色（roles）必须有一个独一无二的名称。
Roles_Permissions角色-权限表
这是连接权限和角色的关系表，没有这里的连接，角色就没有用了...他们仅是一下空的容器。
分配用户到社区和组织（communitiesandorganizations）
Users_Groups表：
是用户（User）和社区（Community）的关系表。
你也许感到困惑，为什莫这里没有className和classPK列在这张表中，
这样的话我们就能够处理所有的实体（例如社区Communites,组织Organization/地区Locations,用户组UserGroups）。
这很难解释...（原文就是这样：
...toohardtoexplain,buttrustus...it'sbetterthisway.）
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中怎么建立组织、用户、用户群、社区等，并为他们配置权限。
（配置具体某个portlet的权限单独说明）。
在liferay中，一般是在功能模块：
EnterpriseAdmin里面配置的。
（1）首先,在AddApplication中加入一个模块：
EnterpriseAdmin，如下图：
组织及用户等一般是在这个模块里面配置的。
EnterpriseAdmin模块显示如下：
点击SearchUsers按钮，会显示所有的用户列表，如下图：
（2）新建一个组织：
点击Organizations项，如下：
要添加一个组织，点AddOrganizations按钮，如下：
输入组织名称，在Type、Conutry、Region中按实际情况选择相应的值。
如果建立的组织是某个组织的子组织，则在ParentOrganization中选择父组织。
保存，即可创建一个组织。
（3）新建一个用户：
点击Users项，如下：
点AddUser按钮，如下：
在相应的项中输入相应的值（其中ScreenName、EmailAddress必须输入），如果用户为某个组织的成员，则在Organizations项中点select按钮，选择组织。
最后保存，即可创建一个用户。
（在用户列表中，点击某个用户，可以修改用户的信息，比如密码等等）
（4）创建一个用户组：
点击UserGroups项，如下：
点击AddUserGroups按钮，如下：
输入相应的值，保存即可创建一个用户组。
（5）创建一个角色：
点击Roles项，如下：
点AddRoles按钮，如下：
输入相应的值，保存即可创建一个角色。
（6）为用户分配组织：
有两个方法，
一是在Users项中，在用户列表中，点击用户名称，显示如下：
在Orgnizations项中选择组织，保存，这样就为用户分配了组织。
另外一种方法是在Orgnizations项中，在组织的列表下，在某个组织中的后面的Action项中，选择AssignMembers，如下：
则出现相应的用户列表，选择相应的用户，点UpdataAssociations,则为相应的用户分配了组织，如下：
（7）为用户分配角色：
在Roles项中，在角色的列表下，选择相应的角色，点Action按钮，选择AssignMembers，如下：
在出现的用户列表中选择用户，点UpdataAssociations，则为相应的用户分配了角色，如下;
（8）为用户设置权限,在Users项中，在用户列表中，选择用户，点Action按钮，选择Permissions，如下：
在出现的页面中选择可利用项（Available）,则列出可利用的用户列表，选择相应的用户，点UpdatePermissions项，如下：
在显示的页面中，配置用户的权限，点Finish保存，则为用户配置了相应的权限（Delete、Impersonate、Permissions、Update、View）。
如下：
（注意：
如果用户属于某个组织、用户组，或者角色，则用户会继承组织，用户组，角色的权限）
（9）为角色配置权限：
在Roles项的角色列表中，在Action按钮中选择DefinePermissions项，如下：
在出现的页面中，可以为角色配置相应的Portlet,Portal的权限，点AddPortletPermission可以选择相应的Portlet，如下：
选择了portlet后，在出现的页面中可以配置角色对portlet的各种操作权限，如下：
保存。
（portal和portlet的情况差不多，这里不再叙述）。
注意：
配置portlet的权限的方法这里算一种，还有另外一种方法是直接在portlet里面配置，稍后再说明。
（10）设置portlet的权限：
（第九项算是一种方法），这里直接在portlet里设置，在相应的portlet中，点配置按钮，可以配置portlet对应的user,organization,usersgroup,roles等的权限。
如下：
这里以Guest用户组做例子来说明。
在上面显示的页面中，选择Guest项，出现的页面如下：
对应的权限有Configuration,View，可以选择相应的权限配置。
比如，要是用户组不能浏览该portlet的内容，则把View移出到Available中。
以上是在liferay中配置权限的简单说明，用户只有去亲自操作摸索，才会有更深入的认识，治理就简要介绍到这里。
升级会员 