Liferay 权限管理

geekcheng

贡献于2012-07-05

字数:30598 关键词: Liferay Portal 门户平台Portal

1、企业管理概述 (1)企业管理Portlet拥有最高的管理功能,它能够访问所有的组织、地区和用户; (2)组织管理Portlet能够访问它自己拥有的信息,以及它属下的组织、地区和用户所拥有的信息,也即能够访问属于它的所有地区和用户; (3)地区管理Portlet能够访问它自己所有的信息,以及它属下的用户所拥有的信息,也即能够访问属于它的所有用户。注意:地区没有下级地区。 (4)三者的区别: 当点击“企业管理Portlet”时:能看到当前用户所创建的所有组织、地区和用户; 当点击“组织管理Portlet”时:能看到当前用户所属于的组织,不同于所创建的组织; 当点击“地区管理Portlet”时:能看到当前用户所属于的地区,不同于所创建的地区。 (5)特别注意一点:从上图来看,只有地区下面才有用户,换句话说,一个用户必须指定一个地区才行? 当新增或编辑一个用户时,也可以不指定地区,即只需要指定一个组织就可以了; 当新增或编辑一个用户时,同样也也可以不指定组织,即只需要指定一个地区就可以了; 当新增或编辑一个用户时,既可以不指定组织,也可以不指定地区,不过从管理上来说,肯定是需要将一个用户指定到一个特定的组织或地区下的。 查询语句: select Users_Orgs.userId, Users_Orgs.organizationId, Organization_.location, Organization_.name from Users_Orgs,Organization_ where Users_Orgs.organizationId = Organization_.organizationId order by Organization_.location,Users_Orgs.userId 图 (二) 说明:这个图要说明的是:企业管理不是不指对某个企业的管理,同样组织管理和地点不是对某个组织,某个地点的管理。它的意义在于说明这是三个不同的等级,管理的范围也是有大有小的。其中企业管理是最大的范转,它可以利用整个系统下面的所有资源,而组织管理是次级的,它能利用的资源范围是在它的组织内部,它不能利用别的组织的资源,组织下面的地点也是同样的。这仅仅是意义上的不同,名称完全可以更换。地点下面才是用户。 如果用户被指派了Administrator角色,那么能够访问【Enterprise Admin】Portlet,否则不能访问该Portlet;在企业管理中可以对用户、组织、地点、用户组、角色进行维护,即增、删、改、查;通过角色定义权限,然后把角色指派给用户、社区、组织、地点、用户组; 2、在Liferay中与管理有关的几个Portlet (1)Admin Portlet (2)Enterprise Admin Portlet (3)Organizations Admin Portlet (4)Locations Admin Portlet (5)Communities Admin Portlet 3、组织和地区管理 (1)组织和地区描述了一个企业的管理层次结构; (2)一个组织代表一个母公司,例如:Liferay USA; (3)一个地区代表一个母公司旗下的子公司,通常按照地理位置来区分,例如:Liferay Chicago、Liferay San Francisco ; (4)一个组织可以拥有任意多个地区; (5)一个用户且仅且只能属于一个组织和地区; (6)组织:湖南工业大学 地区:湖南工业大学老校区 湖南工业大学新校区 湖南工业大学师专校区 湖南工业大学冶金校区 4、用户组管理 (1)用户组不属于任何公司、任何组织、任何地区,纯粹只是为了方便分配角色,为了方便分配权限,而将具有共性(比如:具有相同兴趣爱好等)的一些用户进行分组; (2)一个用户可以属于任意多个用户组; (3)用户组与用户组之间不存在从属关系,即用户组下面不能再分用户组。 5、Portlet管理 (1)在【Enterprise Admin】Portlet中,选中【Plugins】标签页,再选中【Portlets】标签页,如下图所示,从图中可以看出,每个Portlet所必须的角色。 (2)编辑Portlet所必须的角色,如下图所示: (3)表Portlet 主要功能:存储Portlet信息,当在【Enterprise Admin】Portlet中,对Portlet所必须的角色进行修改后,所必需的角色是指,只有当用户具有这些角色,才能对这个Portlet进行操作; 字段:portletId PortletID; 字段:roles 该Portlet所必需的角色; 字段:active 该Portlet的活动状态; 每个Portlet的初始化所必需的角色,存储在portlet-custom.xml中,如下所示: 19 Message Boards com.liferay.portlet.StrutsPortlet view-action /message_boards/view 0 text/html com.liferay.portlet.StrutsResourceBundle priorities Urgent,/message_boards/priority_urgent.png,3.0 Sticky,/message_boards/priority_sticky.png,2.0 Announcement,/message_boards/priority_announcement.png,1.0 ranks Youngling=0 Padawan=25 Jedi Knight=100 Jedi Master=250 Jedi Council Member=500 Yoda=1000 power-user user 6、Liferay Portal中的权限管理类似于面向对象编程中的类的继承机制: 例如: (1)现在有一个组织名为:湖南工业大学,它有三个子组织:湖南工业大学本部、湖南工业大学冶金校区、湖南工业大学师专校区; (2)父组织:湖南工业大学,它拥有三个地区:经管学院、计通学院、理学院; (3)子组织:湖南工业大学师专校区,它拥有一个地区:音乐系; (4)在此,父组织相当于一个超类,子组织相当于一个子类,子类将继承超类所拥有的全部成员变量和成员方法,子组织将继承父组织所拥有的全部地区;而子组织拥有自己新建的地区“音乐系”,父组织以及其他组织不具有“音乐系”。 特别注意:对于用户,在此不适用于继承机制,因为一个用户只能属于一个地区和一个组织,不可以属于多个地区和多个组织,具有唯一性,类似于类中的私有成员变量和成员方法,对于它的子类不可见。 7、与权限有关的各实体定义 与权限有关的实体包括:资源、权限、角色、用户、组织、地区、用户组、社区。 Before using the new security model, an administrator must understand all the entities that compose the model. This chapter will define each of the entities and explain how they are related to the others. (1)Resources A resource is a generic term for any object represented in the portal. Examples of resources include portlets (e.g., Message Boards, Calendar, Document Library, etc.), Java classes (e.g., Message Board Topics, Calendar Event, Document Library Folder, etc.), and files (e.g., documents, images, applications, etc.). Resources can have one of three types of scope – enterprise, community, or individual. The diagram below shows how these types are related. Essentially, an enterprise is the umbrella grouping for all objects within the portal. A resource that has enterprise scope applies to all objects of that type in the company. For example, a Message Board Category resource with enterprise scope encompasses every topic across all communities and all message boards within the enterprise. An enterprise can contain any number of communities. A resource that has community scope only applies to the objects within a particular community. For example, assume that the “Developer" community has several message boards. A Message Board Category resource with “Developer" community scope would encompass all category within the “Developer" message boards. Each community can contain any number of objects. A resource that has individual scope only applies to a single object. For example, assume that the “Developer" community has a message board that contains the topic “Java Issues." A Message Board Category resource with individual scope would have a one-to-one correlation with the “Java Issues" topic. (2)Permissions A permission is defined as an action acting on a resource. The table below gives some example permissions related to message board topics. Example Permissions Enterprise and community scoped permissions can only be assigned to entities (e.g., users, communities, organizations, and locations) via roles. See section 2.3 for more details. Individual scoped permissions can be assigned to a user, community, organization, location, or guest. If a permission is assigned to a community, organization, location, or guest, then all users that are members of that entity receive that permission. In general, permissions are additive. Therefore, a user could receive all three of the permissions in the table above even though they are all of different scope. Consider a situation where a view “Java Issues” permission of individual scope was assigned directly to a user and a view Message Board Category permission of enterprise scope was assigned to the same user through a role (see section 2.3 for more information on roles). Because permissions are additive, the user could receive the view permission for the “Java Issues” category from either the individual or enterprise scope. However, permissions are always checked in the following order: • Individual • Community • Enterprise Therefore, as soon as the system finds the view permission of individual scope, it stops checking and gives the user permission to view. However, also consider the case where the individual scope permission is removed from the user. Now when the system checks, it will not find an individual scope or community scope permission, but it will find the enterprise scope permission. For an administrator, this situation can often lead to a great deal of confusion – a permission is removed from one entity, but the permission is still derived from another entity. As a rule of thumb, if an administrator ever removes a permission from an entity, yet user(s) still has the permission, the administrator should look for derived permissions in the system. (3)Roles A role is a collection of permissions. As such, a role serves no purpose unless permissions are assigned to it. An example role might be a “Message Board Administrator." The role might be assigned permissions to View, Update, and Delete Message Board category resources that have company scope. Ultimately, a user assigned the “Message Board Administrator" role would be able to view, update, and delete any topic for any message board in the company. Roles can be assigned to a user, community, organization, or location. If a role is assigned to a community, organization, or location, then all users that are members of that entity receive the role. (4) Users A user is an individual who performs tasks using the portal. Depending on what permissions and roles that have been assigned, the user either has permission or does not have permission to perform certain tasks. Before logging in to the portal, a user is considered a guest. Guests have their own set of default permissions for objects in the portal, but even these can be customized by administrators. After logging in to the portal, a user is considered a registered user. Registered users can receive permissions in the following ways: • Permission is directly assigned to the user • Permission is assigned to a community that the user belongs to • Permission is assigned to an organization that the user belongs to • Permission is assigned to a location that the user belongs to • Permission belongs to a role that is directly assigned to the user • Permission belongs to a role that is assigned to a community that the user belongs to • Permission belongs to a role that is assigned to an organization that the user belongs to • Permission belongs to a role that is assigned to a location that the user belongs to (5) Organizations and Locations Organizations and locations represent a corporate hierarchy. An organization represents a parent corporation. An example would be Liferay USA. A location represents a child corporation of an organization, often times distinguished by its geographic location. Organizations can have any number of locations. Example locations of the Liferay USA organization might be Liferay Chicago, Liferay San Francisco, and Liferay Los Angeles. A user can only belong to a single organization and location. Both roles and individual permissions can be assigned to organizations and locations. By default, locations inherit permissions from their parent organization. Going back to the example above, if the “Message Board Administrator" role is assigned to the Liferay USA organization, then all members of the Liferay Chicago, Liferay San Francisco, and Liferay Los Angeles locations would inherit the permissions associated with the role. (6) Communities A community is a grouping of users by interest or skill set. For example, a “Pet Lovers" community would consist of users who have an interest in their pets, while a “Tech Support" community would consist of users who have the skills to provide technical support to an organization. A user can belong to any number of communities. NOTE: In previous versions of Liferay, communities were called groups. As far as permissions are concerned, communities are not specific to any organization or location. Both roles and individual permissions can be assigned to communities. (7) UserGroups A user group is a grouping of users. Unlike organizations, locations, and communities, user groups have no context associated with them. They are purely a convenience grouping that aids administrators in assigning permissions and roles to a group of users instead of individual users or assigning a group of users to a community. A user can belong to any number of user groups. Both roles and individual permissions can be assigned to user groups, and every user that belongs to that user group will receive the role or permission. 权限分配是在资源的基础上进行分配的。要理解权限的分配,首先要理解什么是资源。在系统里面,一个portlet是资源,这是对资源粗的划分,还有就是一个portlet具有什么的功能,比如高级文章编审这个portlet具有编辑和审批的功能。我们就可以把这个功能当作资源,分配相应的权限给用户。 权限的定义: 所谓的权限是定义在某个资源上的操作动作(比如:高级文章编审这个portlet资源中 的编辑) 角色的定义: 角色是权限的组合(也就是说一些资源的权限的组合起来,形成一个权限集合,我们把这个集合叫做一个角色)。 用户的定义: 用户就是执行某些操作完成某些任务的人。用户之所以能完成某些操作,依赖给用户分配的角色和权限。具有某个角色和权限,他就具有了某些操作的功能。在没有登录系统之前,所有的用户都被当作是一个Guest。Guest用户具有某些默认的权限。 分配权限的方式有以下几种: 1、 权限(角色)直接分配给用户。 2、 权限(角色)分配给用户所在社区。 3、 权限(角色)分配给用户所在的组织。 4、 权限(角色)分配给用户所在的地区。 资源的定义: 资源 Portlet资源 Model资源 示例:Message Boards Category Category 文件资源 示例:documents 8、层次关系的比较: (1)角色之间不存在层次关系,这与一般RBAC中所提及的角色结构不一样,在一般RBAC中,角色之间有层次关系; (2)组织之间存在层次关系; (3)地区之间不存在层次关系; (4)用户组之间不存在层次关系; 9、在分配权限之前必须要弄清楚几个问题? (1)分配给谁? 角色、社区、组织、地区、用户组、用户 (2)权限来源于哪里? 要搞清权限来源于哪里,即要知道permissionId是什么,就要知道resoureceId和actionId是什么? 权限可以分为静态的权限和动态的权限。 静态的权限:指系统预定义的权限,这来源于xml文档;在权限开发中有DRAC四个步骤,其中第二步就是注册权限,将xml文档中配置好的权限保存到数据库中。 动态的权限:在系统运行过程中,或者说在使用系统的过程中,进行权限分配后,产生的权限。例如:给角色SupportMBAdmin,对Portlet资源Message Boards Portlet,添加Add Category操作后,就会在Permissions_表中新增一条记录。 (3)actionId来源于哪里? 对资源的所有操作信息,来源于xml文档 (4)resourceId来源于哪里? 资源也可以分为静态的资源和动态的资源。 静态的资源:指系统预定义的资源,这来源于xml文档,类似于静态的权限。 动态的资源:在系统运行过程中的产生的资源。例如:增加一个社区、增加一个页面、增加一个栏目、增加一篇文章等,都会在Resource_表中增加相应的记录。 10、二次开发指南中的权限介绍 Liferay Portal采用:用户——用户组——角色——Portlet的关联方式来实现用户权限的管理 用户:隶属于用户组(也可以单独存在); 用户组:具有某种(多种)角色;用户组是对具有相同角色的用户的聚合,只要把用户需要的角色赋给用户组,则该用户组内所有的用户都具有了该角色,具有该角色的所有权限,这样子就简化了用户权限管理; 角色:分配给用户组,也可以直接分配给用户; Portlet:操作某个Portlet需要具有其指定的角色。 11、如何对单个Portlet进行权限控制 例如【Admin】、【Enterprise Admin】、【Organization Admin】、【Location Admin】、【Communities】、【Message Boards】portlet等? 选择一个Porlet,再选择顶部工具栏的【Configure】按钮; 选择【Permissions】标签页,即可对该Portlet进行权限控制; 选择【Users】标签页,选择一个用户,在此选择【Test DLC 1】,如下图所示: 点击【Update Permissions】,即可将相关权限分配给所选择的用户,如下图所示,从图中右边可以看到对Resource:Message Boards Portlet,可选的Actions有:Add Category(添加栏目/类别)、Ban User()、Configuration(配置该Portlet)、View(查看该Portlet)。 12、如何对一个Portlet下的各资源进行权限控制 例如【Organization Admin】portlet下的组织,【Location Admin】下的地区,【Communities】下的社区,【Message Boards】下的Category和Messages等? 选择一个Porlet下的资源,例如选择【Organization Admin】portlet下一个组织【Liferay, Inc】,点击【Actions】,选择【Permmissions】,即可对当前所选的资源的进行权限控制。 13、对资源(Portlet资源或者Mode资源)的初始化操作存储在哪里? 下面是messageboards.xml,Message Boards Portlet的配置文档。 19 ADD_CATEGORY BAN_USER CONFIGURATION VIEW VIEW VIEW ADD_CATEGORY com.liferay.portlet.messageboards.model.MBCategory 19 ADD_CATEGORY ADD_FILE ADD_MESSAGE DELETE PERMISSIONS REPLY_TO_MESSAGE SUBSCRIBE UPDATE UPDATE_THREAD_PRIORITY VIEW ADD_FILE ADD_MESSAGE REPLY_TO_MESSAGE SUBSCRIBE VIEW VIEW ADD_CATEGORY ADD_FILE SUBSCRIBE UPDATE UPDATE_THREAD_PRIORITY com.liferay.portlet.messageboards.model.MBMessage 19 DELETE PERMISSIONS SUBSCRIBE UPDATE VIEW SUBSCRIBE VIEW VIEW SUBSCRIBE UPDATE (1)……定义了Portlet资源的操作(Actions),如下图所示: (2)……定义了模型资源的操作(Actions),如下图所示: (3)……定义了社区对当前资源默认具有的操作,意即默认情况下,在这个社区(组)中Portlet有什么样的行为,以另外一种方式来说,一个用户在最低程度上访问这个社区时能做什么呢? 同样地, 标签…… 定义了当一个客人访问到包含这个portlet的版面时,哪些行为默认是允许的. 所以如果一个访客可以访问到包含公告板portlet的社区页时,访客应该在最低程度上, 根据messageboards.xml文件的定义, 就能够浏览这个portlet(对portlet中的内容并不是必须的).否则,访客就会在portlet中看到一个错误信息. 例如对Message Boards Category,如下图所示: com.liferay.portlet.messageboards.model.MBCategory ADD_FILE ADD_MESSAGE REPLY_TO_MESSAGE SUBSCRIBE VIEW VIEW ADD_CATEGORY ADD_FILE SUBSCRIBE UPDATE UPDATE_THREAD_PRIORITY 14、权限的设计、管理和开发 (1)权限设计 一、权限设计的基本理念:RBAC基于角色的访问控制;ORBAC基于组织机构和角色的访问控制; 二、Liferay中的权限设计思想; 三、其他系统中的权限设计思想:OA系统、门户网站:暨南大学、人大等。 (2)权限管理 一、创建权限; 二、分配权限; 三、使用权限。 (3)权限开发 15、Role Permissions (1)Assigning Company Permissions to a Role Goal: To assign a permission to the “MB Category Admin" role that allows users to view any message board category in the company (i.e., action = View, resource = Message Board Category, scope = Company). 详细过程请参考:liferay_4_portal_administration_guide第47页: 给角色SupportMBAdmin分配权限: 资源:Message Boards Portlet 操作:Add Category scope = 1 Ban User scope = 1 Configuration scope = 1 View scope = 1 企业级作用范围测试: Before: 以用户test.lax.1登录系统,进入My Community 1社区,从下图中可以看到,在Message Boards Portlet中不能进行如下操作:Add Category、Ban User、Configuration、View。 以用户test.lax.1登录系统,进入My Community 2社区,从下图中可以看到,在Message Boards Portlet中不能进行如下操作:Add Category、Ban User、Configuration、View。 After: 以用户test.lax.1登录系统,进入My Community 1社区,从下图中可以看到,在Message Boards Portlet中现在能进行如下操作:Add Category、Ban User、Configuration、View。 以用户test.lax.1登录系统,进入My Community 2社区,从下图中可以看到,在Message Boards Portlet中现在能进行如下操作:Add Category、Ban User、Configuration、View。 (2)Assigning Community Permissions to a Role Goal: To assign a permission to the “MB Category Admin" role that allows users to view any message board category in the company (i.e., action = View, resource = Message Board Category, scope = Company). 详细过程请参考:liferay_4_portal_administration_guide第49页: 给角色SupportMBAdmin分配权限: 资源:Message Boards Portlet 操作:Add Category scope = 2 community = community 1 Ban User scope = 2 community = community 1 Configuration scope = 2 community = community 2 View scope = 2 community = community 2 社区级作用范围测试: Before: 以用户test.lax.1登录系统,进入My Community 1社区,从下图中可以看到,在Message Boards Portlet中不能进行如下操作:Add Category、Ban User、Configuration、View。 以用户test.lax.1登录系统,进入My Community 2社区,从下图中可以看到,在Message Boards Portlet中不能进行如下操作:Add Category、Ban User、Configuration、View。 After: 以用户test.lax.1登录系统,进入My Community 1社区,从下图中可以看到,在Message Boards Portlet中现在能进行如下操作:Add Category、Ban User,但是还是不能进行如下操作:Configuration、View。 以用户test.lax.1登录系统,进入My Community 2社区,从下图中可以看到,在Message Boards Portlet中现在能进行如下操作: Configuration、View,但是还是不能进行如下操作:Add Category、Ban User。 16、Community Permissions (1)Community Portlet Permissions Goal: To understand the concept of a "Community Admin" and how a "Community Admin" can further delegate permissions to members of the community. 详细过程请参考:liferay_4_portal_administration_guide第73页 (2)Community Resource Permissions――Assigning Individual Permissions Goal: To assign a permission to user Test LAX 2 to delete the “Test Category 4" topic in the Support community’s Message Boards portlet. 详细过程请参考:liferay_4_portal_administration_guide第61页 17、Individual Portlet Permissions Goal: To assign the “Add Category" portlet permission to the Test LAX 2 end user. 详细过程请参考:liferay_4_portal_administration_guide第56页 18、Default Permissions Goal: To create a new Message Board Category in the Support community’s message board and assign default permissions to it. 详细过程请参考:liferay_4_portal_administration_guide第59页 19、Individual Permissions Goal: To assign a permission to user Test LAX 2 to delete the “Test Category 4" topic in the Support community’s Message Boards portlet. 详细过程请参考:liferay_4_portal_administration_guide第61页 20、Delegating Permissions So far in this discussion, it has been assumed that a user with the "Administrator" role has been creating roles and assigning permissions to various entities. However, it is also possible for an Administrator to delegate permissions to users which allow them to have certain administrative rights as well. The following sections will explain each of these scenarios using use cases. (1)Portal Permissions Goal: To assign the Test LAX 2 user permissions to add communities, organizations, and roles to the system. 目标:管理门户 详细过程请参考:liferay_4_portal_administration_guide第68页 (2)Community Permissions Goal: To understand the concept of a "Community Admin" and how a "Community Admin" can further delegate permissions to members of the community. 目标:管理社区 详细过程请参考:liferay_4_portal_administration_guide第73页 (3)Page Permissions Goal: To delegate permissions to users such that they will be able to manage pages within their communities. 目标:管理社区中的页面 详细过程请参考:liferay_4_portal_administration_guide第76页 (4)Portlet Permissions Goal: To delegate permissions to users so that they will be able to manage portlets within pages. 目标:管理页面中的Portlet 详细过程请参考:liferay_4_portal_administration_guide第83页 (5)Enterprise Admin Permissions Goal: To delegate permissions to users such that they will be able to manage organizations, locations,users, user groups and roles 目标:管理组织、地区、用户、用户组、角色 详细过程请参考:liferay_4_portal_administration_guide第83页 21、默认权限 (1)将某个对象的权限分配给社区时,只显示一个社区,这个社区就是当前用户所在的社区。 示例1:当前用户: test@liferay.com 用户所在的当前社区:My Community 在Group_表中它的groupId = 83 文件:Document Library Portlet中的Folder 示例1:当前用户: test@liferay.com 用户所在的当前社区:My Community 在Group_表中它的groupId = 83 文件:Message Boards Portlet中的Category 22、权限分配比较 权限类别 详细描述 作用范围 Role Permissions Portal Permissions Portal资源 scope = 1 Enterprise 作用于整个企业,无论哪个社区,无论哪个页面 scope = 2 Community 作用于整个社区 可以选择任何社区 Portlet Permissions Portlet资源,例如:Message Boards Portlet Resource Permissions Model资源(对象的类别) 例如:Message Boards Category Community Permissions Portlet Permissions Portlet资源,例如:Message Boards Portlet 作用范围:Community而且是当前社区 Resource Permissions Model资源(对象的类别) 例如:Message Boards Category Individual Portlet Permissions Portlet资源,例如:Message Boards Portlet 指当前Portlet 仅作用于当前Portlet,不影响同一社区中其他页面上的Portlet Individual Permissions Individual Resources(对象的实例) 作用于当前社区所有页面,因为不同的页面共享Individual Resources。 Delegate Permissions Portal Permissions 管理门户 Enterprise Admin Permissions 管理用户、组织、地区、用户组、角色 Community Permissions 管理社区 Page Permissions 管理社区中的页面 Portlet Permissions 管理页面中的Portlet 粗粒度资源控制 (1)Role Permissions:Portal Permissions Portlet Permissions Resource Permissios (2)Community Permissions:Portlet Permissions Resource Permissios (3)Individual Portlet Permissions 细粒度资源控制: (1)Individual Permissions (2)Page Permissions 23、关于模型资源的问题 模型资源可以分为两类:粗粒度的模型资源(对象的类别)和细粒度的模型资源(对象的实例)。 首先,看一下粗粒度的模型资源,下图中的Message Boards Category和Message Boards Message就是粗粒度的模型资源。 然后,看一下细粒度的模型资源,下图中Test Category、Test Category 1就是对象的实例,一种细粒度的资源。 最后,看一下Resource_表: 查询语句: ------资源------ select resourceId, primKey, ResourceCode.codeId, name, scope from Resource_, ResourceCode where Resource_.codeId = ResourceCode.codeId and name = 'com.liferay.portlet.messageboards.model.MBCategory' 查询结果: 从查询结果中,可以看到:scope = 1和scope = 2指粗粒度的模型资源,即我们在分配Role Permissions和Community Permissions时,要选择的模型;scope = 4指细粒度的模型资源,根据primKey可以找到详细信息。例如primKey = 12101指 Students栏目。 Resources: Message Boards Portlet Actions: Add Category Resources: Message Boards Portlet Actions: Configuration Resources: Message Boards Category Actions: Update Resources: Message Boards Category Actions: View 用户u1 角色r1 角色r1 角色r2 角色r2 用户u2 角色r2 角色r2 用户u3 角色r1 角色r1 24、各权限作用范围比较 (1)Role Permissions Enterprise级 例如:资源Message Boards Portlet,无论在哪个社区、无论在哪个页面,只要该用户具有该角色,则能Add Category。 Community级 只要在指定社区下,无论在哪个页面,都可以Add Category (2)Community Permissions 可以看作Community级:在指定社区下,无论在哪个页面,都可以Add Category。 (3)Individual Portlet Permissions 只作用于当前页面的Portlet,对同一社区中其他页面的Message Boards Portlet不起作用。 (4)Individual Permissions 作用于当前社区中所有页面的Message Boards Portlet,因为各个页面都共享一个细粒度资源,如:Message Boards Category。 (5)Page Permisssions 作用于当前页面 25、几大权限控制的比较 (1)通过角色定义权限――Role Permissions (一)对Portlet进行权限控制――Portlet Permissions (二)对Porlet下的资源进行权限控制――Resources Permissions 例如,通过SupportMBAdmin这个角色对Message Boards Portlet及其下的资源Message Boards Category和Message Boards Message 进行权限控制。 (2)对单个Portlet进行权限控制――Individual Portlet Permissions (3)对Portlet下的资源进行权限控制――Individual Permissions (4)对社区下的页面进行权限控制――Page Permissions 关键问题要弄清楚两点: 一是,Liferay中在哪些地方可以进行赋权操作? 二是,Liferay中可以对谁进行赋权操作? 26、分级权限控制思想 问题:在Liferay中我们可以进行细粒度资源控制,例如:对【Organization Admin】Portlet下的Organization;对Message Boards Portlet下的Message Boards Category可以进行权限分配。 在此,我们可以认为引入了权限设计思想中的分级控制,对权限层层下放。 例如: 湖南工业大学 工学院 理学院 文学院 电气系 计算机系 信息系 (1)湖南工业大学这个组长负责管理工学院、理学院、文学院; (2)工学院这个组长负责管理电气系、计算机系、信息系; (3)计算机系这个组长负责管理整个计算机系; 好处:简化了权限管理,减少了管理员的工作量。 27、相同资源分配权限的比较 (1)存在的问题: 第一个问题:如何区分不同社区中的Portlet?根据什么来区分? 例如:在83社区中有一个Message Boards Portlet,在My Community 1社区中有一个Message Boards Portlet,这是两个不同的资源,这一点从数据库查询出来的结果可以看到,primKey = 11801_LAYOUT_19 指 My Community 1社区中的Message Boards Portlet,primKey = 86_LAYOUT_19 指 83社区中的Message Boards Portlet。 根据primKey来区分,在此例中,primKey取值不同,代表了不同社区下的Message Boards Portlet。 查询语句: select resourceId, primKey, ResourceCode.codeId, name, scope from Resource_, ResourceCode where Resource_.codeId = ResourceCode.codeId and name = '19' and scope = 4 83社区中的Message Boards Portlet My Community 1社区中的Message Boards Portlet 第二个问题:如何区分同一个社区中不同页面的Portlet?根据什么来区分? 例如:在83社区中,有三个页面Home、Test、Test 2,在每个页面上都有一个Message Boards Portlet, 基本原则:在同一个社区中,不同的页面共享一个Portlet。 对于粗粒度资源:Message Boards Portlet来说,不同页面中的Message Boards Portlet是不同的资源,从下图中可以看出: primKey = 86_LAYOUT_19 指 83社区下Home页面中的Portlet,它的resourceId = 5002; primKey = 13411_LAYOUT_19 指83社区下Test页面中的Portlet,它的resourceId = 8937; primKey = 13501_LAYOUT_19 指83社区下Test 2页面中的Portlet,它的resourceId = 6107; 对于细粒度资源:MBCategory来说,不同页面下Message Boards Portlet中的MBCategory是同一个资源,从下图中可以看出: primKey = 12101,name = com.liferay.portlet.messageboards.model.MBCategory指83社区下的Messge Boards Porlet中的栏目Student,三个页面中的Message Boards Portlet都共享这个栏目。 根据primKey取值不同,可以区分不同的栏目,不同社区中的primKey的取值是不同的。 Home页面中的Message Boards Portlet: Test页面中的Message Boards Portlet: Test 2页面中的Message Boards Portlet: (2)对同一社区下不同页面中的Portlet分配Individual Portlet Permissions的比较: 在83社区下有三个页面,每个页面都有一个Message Boards Portlet,从数据库中查询出来的结果: 查询语句: select Group_.name as GroupName,Groups_Permissions.groupId, Permission_.permissionId, Resource_.resourceId, Permission_.ActionId, ResourceCode.codeId, ResourceCode.name, Resource_.primKey, ResourceCode.scope from Group_,Groups_Permissions, Permission_, Resource_, ResourceCode where Group_.groupId = Groups_Permissions.groupId and Groups_Permissions.permissionId = Permission_.permissionId and Permission_.resourceId = Resource_.resourceId and Resource_.codeId = ResourceCode.codeId and Groups_Permissions.groupId = 83 and ResourceCode.name = '19' order by ResourceCode.name, Resource_.primKey 查询结果: 在分配Individual Portlet Permissions之前的状态: 查询语句: select permissionId, actionId, Resource_.resourceId, primKey, ResourceCode.codeId, name, scope from Permission_, Resource_, ResourceCode where Permission_.resourceId = Resource_.resourceId and Resource_.codeId = ResourceCode.codeId and name = '19'and primKey in ('86_LAYOUT_19','13411_LAYOUT_19','13501_LAYOUT_19') order by primKey 查询结果: Home页面: Test页面: Test 2页面: 在分配Individual Portlet Permissions之后的状态,对Home页面中的Message Boards Portlet分配了权限 查询结果: Home 页面 Test 页面 Test 2页面 对上面三个图进行对比,可以看到对Home页面的Message Boards Portlet分配了Individual Portlet Permissions后,其他两个页面并没有改变。 (3)对同一社区下不同页面中的Portlet分配Individual Permissions的比较: Before: 首先,从数据库中查询出对细粒度资源MBCategory:Students栏目和Teacher栏目,可以进行哪些操作,从下面查询出来的结果中,可以看到:primKey = 12101指Students栏目, primKey = 13416指Teachers栏目。 查询语句: select permissionId, actionId, Resource_.resourceId, primKey, ResourceCode.codeId, name, scope from Permission_, Resource_, ResourceCode where Permission_.resourceId = Resource_.resourceId and Resource_.codeId = ResourceCode.codeId and name = 'com.liferay.portlet.messageboards.model.MBCategory' and primKey in ('12101', '13416') order by primKey 查询结果: 其次,从数据库中查询出社区:83,对细粒度资源:Student栏目和Teacher栏目已有哪些操作,目的:与后面分配Individual Permissions给社区83后,进行对比。从查询结果中,可以看出目前对资源:Student栏目,能进行的操作有:ADD_FILE、ADD_MESSAGE、RELY_TO_MESSAGE、VIEW。 查询语句: select Group_.name as GroupName,Groups_Permissions.groupId, Permission_.permissionId, Resource_.resourceId, Permission_.ActionId, ResourceCode.codeId, ResourceCode.name, Resource_.primKey, ResourceCode.scope from Group_,Groups_Permissions, Permission_, Resource_, ResourceCode where Group_.groupId = Groups_Permissions.groupId and Groups_Permissions.permissionId = Permission_.permissionId and Permission_.resourceId = Resource_.resourceId and Resource_.codeId = ResourceCode.codeId and Groups_Permissions.groupId = 83 and ResourceCode.name = 'com.liferay.portlet.messageboards.model.MBCategory' order by ResourceCode.name, Resource_.primKey 查询结果: Home页面: Test页面: Test 2页面: 对上面三个图进行对比,可以看到在三个不同页面中的Message Boards Portlet,它们的Individual Permissions都是一样的。 After: 在Home页面中,给社区83,对资源:Student,增加了操作:ADD_CATEGORY等。 配置权限下的查询结果: Home页面: Test页面: Test 2页面: 对上面三个图进行对比后,可以看到Test页面和Test 2页面中的Individual Permissions也同步改变了。这说明一个问题:对于某个细粒度资源,只要对同一个社区下某个页面中进行权限分配后,其他页面将同步改变,因为同一个社区下不同页面共享细粒度资源。 28、Community权限和其他权限分配的比较 (1)Community Permissions:Assign User Permissions特点: 既定用户,属于当前社区的用户; 既定社区,就是当前社区; 既定Portlet,当前社区中的Portlet; 作用范围:当前社区中的各页面; (2)与Role Permissions不同之处 (一)Role Permissions不针对某个具体的用户,当对其分配权限后,可以指派给用户、组织、地区、用户组、社区、访客,而Community Permissions仅局限于属于该社区的成员。 (二)Role Permissions其权限信息保存在表Roles_Permissions表中; 而Community Permissions其权限信息保存在表Users_Permissions表中。 (三)Role Permissions如果是企业级作用范围,就不用指定某个具体的社区; 两者相同之处: (一)Role Permissions如果是社区级作用范围,和Community Permissions一样都是针对某个具体的社区; (二)两者既可以对Portlet资源分配权限,如Message Boards Portlet;也可以对模型资源分配权限,如Message Boards Category和Message Boards Message。 (3)与Individual Portlet Permissions的不同之处 (一)Individual Portlet Permissions可以分配给用户、组织、地区、社区;而Community Permissions只能分配给用户; (二)两者的作用范围不同 例如:83社区下有3个页面,每个页面都有一个Message Boards Porlet,在Home页面中给用户test lax 1分配Individual Portlet Permissions:Add Category,它的作用范围是当前这个Portlet,对于其他两个页面中的Message Boards Portlet不起作用,即不能Add Category;而Assign User Permissions后,无论在哪个页面都可以Add Category。 (4)与Individual Permissions的不同之处 (一)Individual Permissions是细粒度资源控制;而Community Permissions是粗粒度资源控制; (二)两者性质不一样。 29、在哪些地方可以分配权限 在Liferay中,只有4个地方可以有分配权限的入口: (1)在角色中:Define Permissions (2)在社区中:Assign User Permissions (3)在Portlet中:在Portlet右上角的【Configuration】->Permissions (4)在细粒度资源中:Permissions (5)在页面中:Permissions 30、权限访问矩阵 权限对象模型最终将访问控制模型转化为访问矩阵形式。访问矩阵中的行对应于用户,列对应于操作,每个矩阵元素规定了相应的角色,对应于相应的目标被准予的访问 许可、实施行为。按访问矩阵中的行看,是访问能力表CL(Access Capabilities)的内容;按访问矩阵中的列看,是访问控制表ACL(Access Control Lists)的内容 31、如何分析一个用户的权限? 示例:用户:userId = 888 test.dlc.1@liferay.com 资源:Message Boards Portlet 用户 userId = 888 test.dlc.1@liferay.com 所在的社区 Guest、My Community 1 所在的组织 Liferay Engineering 所在的地区 无 所在的用户组 无 所在的角色 User 资源:Message Boards Portlet 角色:SupportMBAdmin Enterprise BAN_USER Community ADD_CATEGORY CONFIGURATION VIEW 角色:Community Test ADD_CATEGORY BAN_USER CONFIGURATION VIEW 角色:User 无 社区:My Community 1 VIEW 组织:Liferay Engneering 无 地区:无 无 用户组:无 无 32、权限实例 以最简单的例子,消息(通知)发布为例: (1)发布一个寒假放假通知,要求:全校学生和教职工都能收到(在Message Boards Portlet中能看到)? 解决办法: 第一步:用户创建一个消息(寒假放假通知); 第二步:由该用户进行权限分配,如下图所示; 第三步:确定分配给用户、组织、地区、用户组、社区(指当前社区,不能选择其他社区)还是访客;在此,选择分配给组织(【湖南工业大学】这个根组织,这个根组织下所有的子组织,所有的用户都能获取这个权限)。 在数据库中如何存储:上述权限信息存放在OrgGroupPermission表中,只需要一条记录就可以了。 (2)发布一个校领导会议通知,要求只有校领导才能收到? 解决办法: 第一步:用户创建一个消息(校领导会议通知); 第二步:由该用户进行权限分配; 第三步:确定分配给用户、组织、地区、用户组、社区(指当前社区,不能选择其他社区)还是访客;在此,选择分配给用户组(【校领导】这个用户组,那么这个用户组下的所有用户都能获取这个权限)。 在数据库中如何存储:上述权限信息存放在Groups_Permissions表中,只需要一个条记录就可以了。 经过考虑,如果采用角色控制,不容易实现。因为角色只能控制粗粒度的资源,最细也只能控制到Message Boards Category消息栏目,这会对所有栏目都生效,对所有消息都生效,而不针对于某个具体的消息栏目,更不用说某个具体消息栏目下的某条具体消息。 如果要进行细粒度的资源控制,只能将权限分配给用户、组织、地区、用户组,社区。 (3)发布一个院系例会会议通知,要求只有某个院系的教职工才能收到? 解决办法: 第一步:用户创建一个消息(院系例会会议通知); 第二步:由该用户进行权限分配; 第三步:确定分配给用户、组织、地区、用户组、社区(指当前社区,不能选择其他社区)还是访客;在此,选择分配给组织(【某院系】这个组织)和用户组(【教职工】这个用户组),那么【某院系】这个组织下的【教职工】用户就能收到这个消息。 在数据库中如何存储:上述权限信息存放在OrgGroupPermission 表和Groups_Permissions表中,表OrgGroupPermission只需要存储一条记录,表Groups_Permissions也只需要存储一条记录。 (4)发布一个考试通知,要求全校学生能收到? 解决办法: 第一步:用户创建一个消息(院系例会会议通知); 第二步:由该用户进行权限分配; 第三步:确定分配给用户、组织、地区、用户组、社区(指当前社区,不能选择其他社区)还是访客;在此,选择分配给用户组(【学生】这个用户组),那么【学生】这个用户组下的所有用户就能收到这个消息。 在数据库中如何存储:上述权限信息存放在Groups_Permissions表中,只需要存储一条记录就可以了。 33、有关【Add Content】的问题 只有具有Administrator角色或Power Ueser角色的用户才能够【Add Content】增加Portlet;否则,在右上角看不到【Add Content】菜单,即不能增加Portlet,只能使用在社区里已经配置好的Portlet,也不能够删除页面上已有的Portlet,但是可以任意摆放位置。例如:给用户test.dlc.1@liferay.com指派了Administrator角色,当该用户登录后,能够Add Content;而用户test.hkg.1@liferay.com不具有Adminstrator角色,所以该用户登录后,不能Add Content。 能否【Add Content】的根本原因在于:该用户是否有自己创建的社区,如果该用户在自己创建的社区中或者在只属于自己的社区中,那么他就可以【Add Content】。例如:用户888,他具有Power User Role,他有一个只属于自己的社区,当他只属于自己的社区中时,变能【Add Content】;如果他不在自己创建的社区中,如果他在别人的社区中,那么就不能【Add Content】。 当用户888在只属于自己的社区中时,可以【Add Content】,如下图所示:。 当用户888,在别人的社区中时,不可以【Add Content】,如下图所示: 方式一:给用户指派Administrator角色和Power User角色; 方式二:如果在【Communities】Portlet中,先选定一个社区,再将Manage Pages权限分配一个该社区的用户,那么该用户进入该社区后,也可以【Add Content】,如下图所示: 将Manage Pages权限分配给用户Test Lax 1,Test Lax 1登录系统,进入My Community 1社区,如下图所示: 方式三:在【Enterprise Admin】Portlet中,先选定一个角色,给它分配权限;再选定Communities Portlet下资源Community;最后,选定操作:Action--Manage Pages,scope—Enterprise或Community。如下图所示。 方式四:在【Enterprise Admin】Portlet中,先选定一个角色,给它分配权限;再选定Communities Portlet下资源Page;最后,选定操作:Action--Update,scope—Enterprise或Community。如下图所示。

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 15 金币 [ 分享文档获得金币 ]
3 人已下载

下载文档

相关文档