Subadministrators of a virtual portal and their access roles and permissions

When creating a virtual portal using the Virtual Portal Manager portlet, we select a user group of subadministrators who to be responsible for the administration of the new virtual portal.

During the creation of the new virtual portal the Virtual Portal Manager portlet assigns the following default set of necessary access permissions on the virtual portal to the subadministrator group specified:

• Administrator role access permission on the root label of the virtual portal. We cannot change this access permission.

• Administrator role access permission on the virtual portal URL context. We cannot change this access permission.

• Editor role access permission on the administration portlets that are part of the virtual portal. We can change this access permission.

As the subadministrators have the Editor role access permissions on the administration portlets of their virtual portal, they can use these administration portlets to run administrative tasks on the virtual portal. For example, they can add portlets to pages. The default access permissions that are given to subadministrators of virtual portals are limited to managing the pages and documents in the virtual portal. Depending on the specific use case scenario, we might want to give the subadministrators extra permissions to manage more resources, or possibly users. Some of the permissions are not scoped to the virtual portal, but are global to the whole portal installation. This is particular critical for resources available in all virtual portals. For example, if we use a single realm for all virtual portals, the users are available in all virtual portals. A subadministrator who has the permissions to manage a user can manage that user in all virtual portals.

To change the default access permissions for the subadministrators, use one of the following actions:

• To change the default Editor access permission for the subadministrators on the administrative portlets or the list of portlets globally and before creating virtual portals, configure the Virtual Portal Manager portlet accordingly. See Pre-configuring the subadministrators for virtual portals.

• To assign extra access permissions to the subadministrators specifically and after creating a virtual portal, use the master administrator user ID of your initial portal installation and modify those access permissions for them manually in Portal Access Control. To do this, use the User and Group Permissions portlet, the Resource Permissions portlet, xmlaccess.sh, or the Portal Scripting Interface. The consequences differ, depending on where you make the updates:

  • If we do this in the initial portal installation, we can change the access permissions for the subadministrators on the virtual portal as a whole.

  • If we do this in the virtual portal itself, we can change the access permissions for the subadministrators on the individual resources of the virtual portal.

The following list shows the tasks for which we can assign extra access permissions to subadministrators of virtual portals. It also specifies whether an access permission is scoped to the virtual portal or if it is global to the entire portal installation, including all virtual portals. We can assign the permissions for these tasks to subadministrators only using use the master administrator user ID of the initial portal installation.

Granting access permissions to users and groups of virtual portals

This task requires one of the following access permissions:

• Delegator on the group that defines the users of the virtual portal. This way is the preferred option, as the access permission is limited to the virtual portal.

• Delegator@Groups or Delegator@Users. Both of these access permissions apply globally to the entire portal installation, including all virtual portals.

Cloning portlet applications, for example, the web clipping portlet

This task requires Editor@Portlet Application. This access permission applies globally to the entire portal installation, including all virtual portals.

Access permissions for policies.

To manage policies, subadministrators need different access permissions, depending on the task that we want the subadministrative user to be able to complete. For example, to delete policies, a subadministrator needs Manager@Policy and User@Business Rules. This access permission is the highest permission. These access permissions apply globally to the entire portal installation, including all virtual portals.

Use xmlaccess.sh

This task requires Security Administrator@Portal and Editor@XML access. These access permissions apply globally to the entire portal installation, including all virtual portals.

Manage portal search collections

This task requires Editor@Virtual Resource PSE_SOURCES. This access permission applies globally to the entire portal installation, including all virtual portals.

Manage URL mappings

This task requires Editor@parent context for parent mappings and Manager@context for URL mappings. These access permissions apply globally to the entire portal installation, including all virtual portals.

Manage tags and ratings

This task requires Manager@Tags and Manager@Ratings. These access permissions apply globally to the entire portal installation, including all virtual portals.

Manage personalization rules

This task requires the following access permissions:

• Privileged User on the following portlet applications:

  • Personalization Editors

  • Personalization Navigator

  • Personalization Picker

• Manager@the Personalization Rule

These access permissions apply globally to the entire portal installation, including all virtual portals.

Granting virtual portal administrators access to web content libraries

Virtual portal administrators do not automatically have access to work with web content libraries when they are using the administration portlet. To enable a virtual portal administrator to work with web content libraries, assign them access to either the JCR content root node or individual web content libraries:

• We can assign virtual portal administrators access to the JCR content root node using the Set access on root button in the Web Content Library view of the Administration portlet. See Set root access for all web content libraries in the Portal Content help.

  • Assign virtual portal administrators administrator access to the JCR content root node to enable them to create new libraries and view, edit, and delete all existing libraries.

  • Assign virtual portal administrators contributor access to the JCR content root node to enable them to create new libraries and view, edit, and delete libraries they created.

• We can also assign virtual portal administrators access to libraries they did not create by editing the access settings of individual libraries.

Templating sample content is provided by default with WebSphere Portal. This sample content is available from the Create Content tab of the site toolbar. To use the sample content with a specific virtual portal, syndicate the following web content libraries to the virtual portal:

• Template Page Content 3.0

• Web Content Templates 3.0

If we fail to syndicate these libraries, the portal shows an error when adding the sample content to a page.

Parent Virtual portal roles and their capabilities

Related concepts:

Control access
Set resource permissions
xmlaccess.sh

Related tasks:

Pre-configuring the subadministrators for virtual portals
Set user and group permissions

Related reference:

Portal Scripting Interface

Related information

Technotes for virtual portals