liferay 权限管理

liferay权限的分类，分为动态权限和静态权限

静态的权限：指系统预定义的权限，这来源于xml文档；xml文档中配置好的权限保存在数据库中。

动态的权限：在系统运行过程中，或者说在使用系统的过程中，进行权限分配后，产生的权限。

 

与权限有关的实体包括：资源、权限、角色、用户、组织、地区、用户组、社区。

1、各实体的定义

Resource ：在Liferay中，可以简单的认为Resource是一个个可以操作的实体对象。一般resources包括portlets（如：Message Boards，Report， etc），java类（如：Message Board Topics，Report Events， etc），flies（如：documents，images，etc）。资源可以用三种范围：enterprise, community, or individual；关系如下图所示：

       

Permission ：所谓的权限是定义在某个资源上的操作动作（比如：高级文章编审这个portlet资源中的编辑）。

Role ：角色是权限的组合（也就是说一些资源的权限的组合起来，形成一个权限集合，我们把这个集合叫做一个角色）。

Users ：用户就是执行某些操作完成某些任务的人，隶属于用户组（也可以单独存在）。在没有登录系统之前，所有的用户都被当作是一个Guest。

Organizations and Locations ：是Groups的集合。

Communities/Groups ：社区，用户自定义的用户集合。

UserGroups ：用户组，不属于任何公司、任何组织、任何地区，纯粹只是为了方便分配角色或权限，而将具有共性（比如：具有相同兴趣爱好等）的一些用户进行分组。

2、实体间的层次关系

（1）角色之间不存在层次关系；

（2）组织之间存在层次关系；

（3）地区之间不存在层次关系；

（4）用户组之间不存在层次关系；

3、特别注意:

（1）当新增或编辑一个用户时，可以不指定社区，只指定一个组织；

（2）当新增或编辑一个用户时，可以不指定组织，只指定一个社区；

（3）当新增或编辑一个用户时，可以既不指定组织，也不指定社区，不过为了方便管理，一般会为用户指定一个组织或社区。

（4）为用户指定组织后，Liferay会为用户指定社区。

 

http://www.360doc.com/resaveArt.aspx?articleid=10797583&isreg=1

 

 

主要实体
首先从表或者本人更喜欢称作实体的表开始，换言之，他们界定的实体定义了关于权限和角色的东东。
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的用户都能够留言了，而不管他们是否属于这个社区。
在另外的场景下，管理员想要进行更多的限制，用户必须属于指定的组织才能发表留言，他就可以通过设置“排除权限”来完成。

http://intelli.blog.51cto.com/141419/97447 

 

 

 

liferay6 权限管理

用户：用户名、密码、组织机构、社区、用户组、角色、页面、分类。

 

组织机构：显示用户所属的机构或区域，

       区域有管理页面（区域自己的页面）、管理团队（可以给团队分配成员）、分配角色（角色的类型必须是组织机构）、分配成员(分配具体的用户)、添加新用户、查看用户（取消激活）

       常规机构有管理页面、管理团队、分配用户角色、分配成员、添加用户、查看用户、添加常规机构（下级机构）、添加区域（下级区域）、查看下级机构。

 

社区组织：用户可以属于一个或多个的社区，并且能够集成所属社区的权限和角色，添加一个社区，管理页面、管理团队、分配用户角色、分配成员、离开（或者加入，离开时用户不可以访问页面，加入时才可以访问页面）

 

用户组：添加、访问权限(即那些角色可以访问)、管理页面（添加页面）、分配成员（分配具体的用户）、查看用户。当用户首次与用户组相关联时，属于此用户组的用户将把这些页面复制到他们的用户页面。

 

角色：添加角色;定义该角色的使用权限，比如是否可以添加某个portalet页面;给角色分配成员，分配的成员可以是用户、社区、机构组织、用户组