Access control for managed pages

Overview

For managed page, in addition to the standard page access control, we can also apply WCM access control features, such as to workflow and syndication.

When creating a managed page in the portal, a corresponding page item is created in a web content library. We can view and change access control settings for a managed page in two ways:

• Navigate to the page and using the site toolbar

• Open the page in the authoring portlet

Synchronization ensures that permissions are coordinated between the portal page and the web content page item.

With managed pages, portal pages and WCM are aware of the same roles; however, some roles are effectively ignored in WCM.

For example, the roles of Privileged User and Markup Editor are used with portal pages to support features such as personalizing a page. In WCM, these roles have no effect on access control. When performing a web content action on a managed page, like previewing, publishing, or syndicating the page, WCM accounts for the portal roles. This awareness ensures that pages retain their appropriate permissions from the roles.

In WCM we can grant access to virtual groups (authors, owners, creators) through the web content authoring portlet or as part of a workflow stage. Portal pages do not provide an equivalent mechanism. When you grant permissions on a page item to users or groups with the virtual groups, direct role mappings are assigned on the portal page. These role mappings ensure that equal permissions are applied. The owner virtual group, however, is limited to a single owner for page items in WCM. The owner of the portal page is automatically synchronized with the owner of the page item. This owner has the same set of allowed actions as the Manager role, as described in the Ownership section of Roles. If we are using author or creator groups for access control management in WCM, use only the authoring portlet to perform access control tasks. Do not use the site toolbar in the portal interface to revoke permissions, because doing so can lead to a potentially complex assignment of permissions.

With portal pages, traversal support provides implicit permissione that enable users to navigate through a page hierarchy. For example, a user might have permission to access a child page but might not have permission to access the parent page. Because of traversal support, the user is permitted to navigate to the child page. However, traversal support is not provided for web content items. Content authors that use the authoring portlet must be assigned the User role on all pages higher than the child page to navigate to editable content. Without this access permission, the editable content is not visible in the authoring portlet, even though the author can access the page. Typical page administration tasks can still be performed from the page.

With traditional portal pages, we can grant permissions on the virtual resources PORTAL and CONTENT_NODEthat inherit permissions to the complete page hierarchy. This inheritance is described in Resources. We can also specify a similar inheritance for web content libraries that inherit from the root node. Because permissions for managed pages are synchronized between portal pages and page items in WCM, such inheritance is problematic. This inheritance can result in different effective permissions on portal pages and content items. Although we can manage permissions correctly either through the page or the authoring portlet, the preferred approach is through the page. If you grant permissions to the entire page hierarchy with inheritance, grant this permission on the root resource for the page hierarchy (wps.content.root page). As the permission on this page node is synchronized to the corresponding page item in WCM, the effective permissions are automatically synchronized throughout the hierarchy.

When working with managed pages, we can apply access control to page items through workflow stages and actions, as described in Workflow and change management In addition to permissions from the workflow, we can also modify permissions on the page with the site toolbar. Changes that you make with the site toolbar override the access permissions in effect with the current workflow stage. When the next workflow stage is entered, changes from the site toolbar are reset and the permissions specified by the workflow stage take effect.

We cannot use externalized roles or role mappings with managed pages. Pages cannot be externalized while being edited in a project. Similarly, externalized resources cannot be added to a project.

Required permissions

The following permissions are required for typical actions with managed pages.

Action	Required permission
Access a project view in the site toolbar	User on the WCM_REST_SERVICE virtual resource
View a project in the site toolbar	User on the WCM_REST_SERVICE virtual resource, in addition to the permissione required to view a specific project User on the selected project
Create a project	Contributor on the Portal Site library User on the selected project
Create a draft of a published page by editing the page in a project	Editor on the page User on the selected project
Create a draft of a published page with the Create Draft action in the site toolbar.	User on the page and Approver on the corresponding web content page item. For details, see Approver role for creating draft pages. User on the selected project
Create a draft child page under a parent page in a project	Contributor or Editor on the parent page User on the selected project
Preview a project	Can Run As User on the USERS virtual resource The user that is impersonated requires at least User access to the current portal page. If an anonymous user does not have access to the page, the As Unauthenticated User preview option is not available in the site toolbar. In addition, if we select the As User preview option, we cannot select users that do not have access to the page. User on the selected project By default only users and unauthenticated users that have explicit access to the project can preview the project. We can globally assign access for users or unauthenticated users to view all items in all libraries and projects in a specific virtual portal or the default virtual portal. To assign these rights, use the Set root access setting in the library administration portlet (Administration | Portal Content | Web Content Libraries).
Create web content by adding web content viewer to a page. The viewer is configured to create and render content from a web content library.	Editor on the page User on the viewer portlet No library permissions are enforced.
Perform inline editing of content on a page	Editor on the page Appropriate permissions on the library containing the content

For the required permissions for portal pages and web content items, see Access permissions for portal pages and User roles and access for web content items.

The default set of access control permissions for anonymous users and for members of the All Authenticated Users group are described in Initial Access Control Settings. With managed pages, the following default permissions exist:

• Anonymous users can view projects and have User access to the Portal Site library.

• Members of the All Authenticated Users group can create new projects and have Editor access to the Portal Site library. This access ensures that users can perform inline editing tasks. We can restrict access as needed with the library administration portlet.

To modify a portal page or page item, you require only those permissione needed to perform the action from the user interface or programming API. You do not also require permissions for the underlying synchronization actions that take place automatically. These automatic updates are performed with system privileges.

For example, we might add a portlet to a page using the site toolbar. In this case, you require sufficient permissions on the page that we are editing and on the portlet that we are adding. You do not need additional permissions for the internal updates to the corresponding items in the web content library.

Approver role for creating draft pages

With managed pages, we can use a workflow to enable business users to create draft versions of pages that they are normally not allowed to edit. By using a workflow in this way, you accomplish two things:

• We provide business users with the ability to modify pages.

• We can still ensure that the drafts are reviewed and approved by technical users before the changes are published to the external site.

Typically a user with User access to a page has permission only to view the page. But if the user also has Approver access to the corresponding page item in the Portal Site library, the user can create page drafts. When a user has this access, the user can navigate to the portal page and use the site toolbar to create a draft.

To enable business users to create draft pages:

1. In the Portal Site library, assign a workflow to the page items that correspond to the portal pages you want users to modify. By default, page items are not managed in a workflow.

2. Edit the publish stage of the workflow, and update the access control properties to add the users to the Approver role.

3. Edit the initial draft stage of the workflow, and update the access control properties. Add the users to the roles that correspond to the permissione that the users require on the draft pages that they create.

Contributor role for creating child pages

Users with Contributor access to the published version of a page can create child pages under that page. When in edit mode on the parent page, contributors can use the site toolbar to create a child page.

Parent: Administer managed pages
Related:
Workflow and change management