Portal access control scenarios
Overview
The following examples use a hypothetical portal user called Penelope and a hypothetical group called the Operations group. The tasks described here can be performed using either the administrative portlets or the XML configuration interface.
Give a user full access to the portal
Give the user the Administrator@Portal role. The Administrator@Portal role permits unrestricted access to all portal resources except the private pages of other users.
Give users this role in one of two ways:
- Add users to a group that has the Administrator@Portal role. The <wpsadmins> user group automatically receives the Administrator@Portal role during the portal installation. Use the Manage Users and Groups portlet to assign users to this group.
- Explicitly assign the Administrator@Portal role to specific users. Use the Resource Permissions portlet or the User and Group Permissions portlet to to give users this role.
Manage Applications portlet
Suppose that Penelope needs to manage certain portlet applications. To allow Penelope to use the Manage Applications portlet give her the following roles:
User@<Web_Module>: Allows Penelope to see information contained in a Web Module and to use the Manage Applications portlet to navigate to the Portlet Applications that are contained in this Web Module. Assign Penelope to a User role on each Web Module that she needs to access. Manager@<Portlet_Application>: Allows Penelope to administer the portlet application. Assign Penelope to a Manager role on each Portlet Application that she needs to administer. There are two ways to give Penelope these roles:
- Add Penelope to a group that has these roles. Use the Manage Users and Groups portlet to assign her to this group.
- Explicitly assign the roles to Penelope. Use the Resource Permissions portlet or the User and Group Permissions portlet to give her these roles.
View portlets and portlet applications
For example, suppose that a user, Penelope, needs to view a portlet. Give Penelope the following three roles:
- User@<portlet_page> or User@Portlet Applications.
If Penelope needs to view all portlets or portlet application instances, give her the User@Portlet Applications role. If she needs to view a restricted set of portlets or portlet applications, assign her the User role only on the specific portlet or portlet application instances that she needs to view.
- User@<portlet_page> or User@Content Nodes.
The User@Content Nodes role permits Penelope to navigate through all nodes within the portal without explicitly assigning her to roles on every page. If Penelope needs to navigate through a restricted set of portlets or portlet applications, assign her the User role only on the specific pages containing the portlets that she needs to access.
- User@<web_module_name> or User@Web Modules.
The User@Web Modules role is best if Penelope needs access to portlets or portlet applicaitons in many Web Modules. If Penelope needs access to a restricted set of Web Modules, assign her the User role only on the Web Modules containing the portlets and portlet applications that she needs to access.
There are two ways to give Penelope these roles:
- Add Penelope to a group that has these roles. Use the Manage Users and Groups portlet to assign Penelope to this group.
- Explicitly assign the roles to Penelope. Use the Resource Permissions portlet or the User and Group Permissions portlet to give Penelope these roles.
Allow users to access a page and some subset of its child pages
Create an inheritance block on the appropriate page. For example, give the Operations group the Editor@Market News Page role. This allows members of the Operations group to edit the Market News page and all of its current and future child pages, including the Europe Market News page and the USA Market News page. To allow the Operations group to edit the USA Market News page, but not the Europe Market News page, insert an inheritance role block for the Editor role type on the Europe Market News Page. Use the Resource Permissions portlet or the XML configuration interface to insert this role block. This role block prevents members of the Operations group (and all other users and groups with an inherited or implicit Editor role on any parent pages of the Europe Market News page) from editing the Europe Market News page and all of its current and future child pages.
Allow users to access a portlet on a page
Give the group a role assignment on both the page and the portlet. Role assignments on a page do not contain access rights for portlets that appear on the page. Use the Resource Permissions portlet, the User and Group Permissions portlet, or the XML configuration interface to assign these roles.
For example, suppose there is a Market Targets portlet on the Market News Page. Give the Operations group (or a user group that contains the Operations group) the Editor@Market Targets Portlet role and the Editor@Market News Page role.
Allow users to access a page, but not its child pages
Use the Resource permissions portlet to create a propagation block on the appropriate page. For example, give the Operations group Editor access to the Market News page. To prevent this group from editing the USA Market News page and the Europe Market news page, create a propagation block for the Editor role type on the USA Market News page. This role block prevents the Operations group (and all other users and groups with an inherited or implicit Editor@Market News Page role) from editing all current and future child pages of the Market News Page.
Allow users to view and personalize a page and all of its child pages
Give the group the Privileged User role on the page and any portlets that appear on the page or its child pages. For example, give the Operations group to the Privileged User@Market News Page role. This allows all members of this group to view and personalize the Market News page and all of its current and future child pages. Then give the Operations group the Privileged User role on all portlets and portlet applications that appear on the Market News page and any of its child pages.
Giving the Operations group the Privileged User role instead of the Editor role allows members to create new private pages that are children of the Market News Page, but prevents members from creating new public pages.
The Editor role blocks that are created in the previous examples do not affect Privileged User roles in any way.
Assign roles on a specific resource to members of a specific group
For example, to allow Penelope to assign the Operations group to the role Privileged User@Market News Page, do either of the following steps:
- Give Penelope the Privileged User@Market News Page, Security Administrator@Market News Page, and Delegator@Operations Group roles. This allows her to assign the Operations group (or individual members of this group) to the Privileged User@Market News Page role or the User@Market News Page role. Penelope cannot assign anyone to the Editor@Market News Page role because she is not an Editor on the Market News Page. Penelope cannot assign the Global Marketing group to the Privileged User@Market News Page role unless the Global Marketing group is a member of the Operations group.
- Give Penelope the Administrator@Portal role. This allows her to assign any user or group to any role on any resource.
To administer access control through the administrative portlets, Penelope must have role assignments that allow her to view the User Group Permissions or the Resource Permissions portlets and the pages that contain these portlets. To administer access control through the XML configuration interface, Penelope must have a role assignment that allows her to access the XmlAccess virtual resource.
See also