Administering virtual portals

This topic describes how you can scope your WebSphere Portal to have multiple virtual portals. This topic has the following sections:

Note: Before you start creating or administering virtual portals, read all of the information in Plan for virtual portals for planning purposes.

Administering virtual portals and their content comprises the following tasks:

Use the following tools to administer your virtual portals:

The following table shows how you can use these portal tools to administer virtual portals:

Administrative task Portlet for this task Configuration task XML configuration interface
Add and configure the user repository for the virtual portal This is a manual task.
Preconfiguring virtual portals This is a manual task.
Configure the subadministrators for a virtual portal Access control portlets     ---     X
Create a virtual portal Manage Virtual Portals     X     ---
Filling a virtual portal with initial content Manage Virtual Portals     ---     X
Listing all virtual portals Manage Virtual Portals     X     ---
Modifying a virtual portal Manage Virtual Portals     X     ---
Delete a virtual portal Manage Virtual Portals     X     ---

The following sections provide more information about these tasks and how you perform them.

 

Add and configure the user repository for a virtual portal

When you enable security on a portal installation, you select a custom user registry. Member Manager is the typical choice. In this case you enable security by using one of the configuration tasks enable-security-wmmur-ldap or enable-security-wmmur-db, depending on whether you use an LDAP or a database.

For an overview of portal security refer to Enable security and Security Concepts. For more details about how to configure Member Manager and realms for virtual portals refer to Using multiple realms and user registries. Review the sections about the Configuration and Sample Configuration. These sections list samples of the required xml files.

As an alternative choice, WebSphere Portal V5.1 also supports the WebSphere Application Server LDAP custom user registry. You enable the user registry by using the configuration task enable-security-ldap. In this case you cannot use realms.

Protection of Virtual Portal URL Mappings in is ESM possible. Adapt Login Link in VP specific Theme to point to protected URL -> intercepted by ESM for authentication. Alternative: Access protected URLs directly. Virtual Portal URL Mapping stable in URL (since WP 5.1.0.1). Allows to use TAM Protected Object Policies for VPs (e.g. Step Up authentication)

 

Preconfiguring virtual portals

When you use the Manage Virtual Portals portlet to create a virtual portal, the new virtual portal is set up with content and with a set of access rights on the content for the subadministrator group that you specified. You can modify the default content and the subadministrator access rights globally, that is for all virtual portals that you create, before you create virtual portals. You do this by configuring the Manage Virtual Portals portlet. The following sections provide instructions about how to do this.

 

Preconfiguring the default content for virtual portals

You can customize the default content for virtual portals by modifying or replacing the XML script that specifies the initial content for virtual portals. This default XML script file is located in the portal directory WAS_install\installedApps\hostname\wps.ear\wps.war\virtualportal and is named InitVirtualPortal.xml . For details about how to work with the XML configuration interface refer to the XML configuration interface.

Advanced administrative users can replace the default XML script by their own custom XML script. To do this, proceed as follows:

  1. Place you custom XML script in the directory WAS_install\installedApps\hostname\wps.ear\wps.war\virtualportal .
  2. Open the Manage Portlets portlet by clicking Administration > Portlet Management > Portlets.
  3. Select the Manage Virtual Portals portlet by clicking Virtual Portal Manager.
  4. Click the Configure Portlet (wrench) icon.
  5. Edit the SCRIPT_INIT_VP parameter of the portlet. Replace the value InitVirtualPortal.xml with the name of your custom XML script. You might have to take a note of the parameter and remove it, and then enter the parameter with the name of your XML file.
  6. Click OK to save your changes.

 

Preconfiguring the subadministrators for virtual portals

To configure the roles and access rights that are assigned to subadministrators on portlets of a virtual portal globally and before you create a virtual portal, proceed by the following steps on your initial portal installation:

  1. Open the Manage Portlets portlet by clicking Administration > Portlet Management > Portlets.
  2. Select the Manage Virtual Portals portlet by clicking Virtual Portal Manager.
  3. Click the Configure Portlet (wrench) icon.
  4. Perform the following steps, depending on the requirements for your virtual portals:
    1. If you want to change the list of portlets to which the subadministrators have access:
      1. Edit the portletListNeedAccess parameter of the portlet. Remove those portlets for which you want the subadministrators of your virtual portals to have no access rights.
      2. Add portlets as required by adding the unique names of the portlets to the list. You might have to take a note of the list and remove the parameter, and then enter the parameter with your updated list.
      The default list contains all portlets listed under Content of a virtual portal.
    2. If you want to change the access rights that are granted to the subadministrators on the portlets of virtual portals, edit the actionSetName parameter of the portlet and change the role that you want to assign to the subadministrators to the role that fits your requirements. The default role is EDITOR. You might have to take a note of the parameter and remove it, and then re-enter the parameter with the updated value. You can enter the following values:

      Administrator, Security Administrator, Delegator, Manager, Privileged User, User.

      Note: Subadministrators have the roles that you assign to them on all the portlets that are listed under the portletListNeedAccess parameter of the Manage Virtual Portals portlet (see the previous step).

  5. Click OK to save your changes.

 

Create a virtual portal

As a master adminstrator you can create virtual portals by using the Manage Virtual Portals portlet. The following sections describe how you do this.

As an alternative you can also use the appropriate configuration task to create virtual portals. For details about the configuration tasks for administering virtual portals refer to Using configuration tasks for administering virtual portals.

When you use the Manage Virtual Portals portlet to create a virtual portal, you specify the following attributes:

  • The title of the virtual portal. This title is later displayed in the list of virtual portals in the Manage Virtual Portals portlet. The title is not visible for end users of the virtual portal.
  • A description for the virtual portal. This field is optional.
  • The user friendly URL of the virtual portal. This URL is mapped to the actual internal URL of the virtual portal. You can give the friendly URL to the users of the virtual portal. They can use it to access the virtual portal without having to remember the internal URL.
  • The user group of subadministrators who will be able to administer the virtual portal.
  • The realm that represents the user population for the virtual portal. This field is only shown if your portal configuration supports realms.
  • The theme of the virtual portal.

If you use the configuration task create-virtual-portal to create a virtual portal, the virtual portal is created without content. For more detail about filling a virtual portal with content refer to Filling a virtual portal with content.

 

Filling a virtual portal with content

When you create a virtual portal by using the Manage Virtual Portals portlet, the portlet fills the new virtual portal with default content. For more information about the default content for virtual portals and how you configure it, and about how you can add more portal content refer to Administering the portal content and resources for virtual portals. You can also use the portal XML configuration interface to add content to a virtual portal.

If you use the configuration task create-virtual-portal to create a virtual portal, the virtual portal is created without content. In this case use the portal XML configuration interface to fill the virtual portal with content.

For more information about the XML configuration interface and how to use it refer to The XML configuration interface.

 

Configure the subadministrators for virtual portals

You can administer the subadministrators of a virtual portal as required by using the Portal Access Control of your initial portal installation.

When you create a virtual portal by using the Manage Virtual Portals portlet, you select a user group of subadministrators that you want to be responsible for the administration of the new virtual portal. During creation of the new virtual portal the Manage Virtual Portals portlet creates a set of necessary access rights on the virtual portal for the subadministrator group that you specified. This includes EDITOR role access rights on the administration portlets that are part of a virtual portal (refer to Content of a virtual portal). As a result, the subadministrators of a virtual portal can perform administrative tasks on the virtual portal with these administration portlets. If you want to change these default access rights for the subadministrators, you can do one of the following:

  • To change the roles and access rights for subadministrators on portlets globally and before you create a virtual portal, configure the Manage Virtual Portals portlet accordingly. For details about how to do this refer to Preconfiguring the subadministrators for virtual portals.
  • To change the access rights for subadministrators specifically and after creating a virtual portal, use the Portal Access Control portlets:
    • If you do this in the initial portal installation, you can change the access rights for the subadministrators on the virtual portal as a whole.
    • If you do this in the virtual portal itself, you can change the access rights on the individual resources of the virtual portal.

The following two portlets require that you assign additional roles and access rights on them to the virtual portal administrators so that they can use the full functionality of the portlet:

Do not grant the subadministrators of virtual portals the access rights to perform any installation related tasks, such as installation of portlets or themes. An unstable or malicious portlet that is installed in one virtual portal can destabilize the entire portal installation, as all virtual portals share the same Java Virtual Machine. Typically, installation related tasks should only be done by the master administrator of the portal installation.

If you use the configuration task create-virtual-portal to create a virtual portal, this configuration task does not assign roles to the subadministrators of the virtual portal. In this case assign the required roles manually or by using the portal XML configuration interface. For more information about the XML configuration interface and how to use it refer to The XML configuration interface.

 

Listing all virtual portals

You can list all virtual portlets by using either the Manage Virtual Portals portlet or using a configuration task.

 

Modifying a virtual portal

Use the Manage Virtual Portal portlet to change the following settings of an existing virtual portal:

  • The title of the virtual portal
  • The description of the virtual portal
  • The realm of the virtual portal
  • The theme of the virtual portal.

You can perform the same updates by using a configuration task.

 

Delete a virtual portal

You can delete a virtual portal by using either the Manage Virtual Portals portlet or the appropriate configuration task. After the virtual portal resource has been deleted, the scoped resources of that particular virtual portal are deleted at a later time by a scheduled cleanup service. The URL Mapping that was created when the virtual portal was created is also deleted. The following resources are not deleted:

  • The unscoped resources that were available in the virtual portal; they belong to the initial portal installation and are therefore not deleted.
  • Additional URL mappings which administrators might have created manually are not deleted.

You can also delete a virtual portal by using a configuration task.

 

Administering the portal content and resources for virtual portals

When you create a virtual portal by using the Manage Virtual Portals portlet, the portlet also creates default portal content and resources for the virtual portal. The default content of a virtual portal is listed under Content of a virtual portal. In general, you can administer portal resources for a virtual portal just like you do for a normal WebSphere Portal installation.

You need to be aware that some resource types are scoped to a particular virtual portal and cannot be accessed from outside of that virtual portal. Such scoped portal resource types are assigned to only that one portal. Sharing of these resource types between virtual portals is not possible. This restriction is imposed by the portal system and provides a secure isolation between virtual portals. You cannot change this behavior.

Other resource types are not scoped. They are shared among all virtual portals of the same installation. If you want to restrict such resource types to particular virtual portals, you can define their visibility by using Portal Access Control. These access restrictions should usually be defined by the master administrator of the portal installation. For more details about scoping of portal resources for virtual portals refer to Separation between virtual portals.

If you want to change the content of virtual portals, you can do this by one of the following ways:

  • To change the content globally and before creating a virtual portal, modify the XML script that specifies the initial content for virtual portals. For details about how to do this refer to Preconfiguring the default content for virtual portals.
  • To change the content specifically and after creating a virtual portal, use either of the following portal tools:
    • Use the Manage Pages portlet of the virtual portal. You can have the subadministrator of the virtual portal do this.
    • Use the XML configuration interface to import content into the virtual portal. This can only be done from the initial portal installation.

 

Administering the users for virtual portals

As the master administrator of the portal installation you assign administrative users for the virtual portals. These virtual portal subadministrators can manage the access rights of the user population of the virtual portal for which they are responsible. When you use realms to separate the user populations of the virtual portals from each other, configure the realms manually in a Member Manager configuration file. This is typically done by the master administrator of the portal installation.

When you create a virtual portal, be aware of the following implications:

  • The All Authenticated Users group is given the Privileged User role on the virtual portal that you create. This means that access rights that you configured for users on the initial portal installation are not passed on to the virtual portal. For example, if you restricted access rights to some resources for users on the initial portal installation, these restrictions do not apply to the users of the virtual portal.
  • The All Authenticated Users group is valid over all portals that share the same realm. This means that users who are in a realm or user group that belongs to more than one virtual portal, these users have the assigned access rights on all virtual portals to which they have access.

If you want to change these default access rights for the users, you can do one of the following:

  • To configure the scope of access rights for users before creating a virtual portal, configure your realms and user groups accordingly.
  • To change the access rights of users of a virtual portal after creating a virtual portal, use the Portal Access Control portlets in that virtual portal. You can have the subadministrators of the virtual portal perform this task.

 

Administering content and search with virtual portals

Portal Search and Web Clipping are not aware of virtual portals. A document that is available in the initial portal installation is also available in all virtual portals of the installation. The document has multiple URL mappings, one for each virtual portal. Therefore create and maintain a separate search index for each virtual portal.

Document libraries that are used by the Document Manager portlet and Personalization are not aware of virtual portals. A document library that is available in the initial portal installation is also available in each virtual portal, if the Document Manager portlet or Personalization is available in that virtual portal and is configured to use that document library. Searching for a document in a document library will produce a document reference (URL) that is different in each virtual portal, but points to the same document in the document library. To provide separation of content within virtual portals, use separate document libraries for each virtual portal. To provide content collaboration between virtual portals, use the same document libraries between virtual portals.

 

Using the Manage Virtual Portals administration portlet

For improved manageability of virtual portals, WebSphere Portal provides a new administration portlet. It is named Manage Virtual Portals. It allows you to create additional virtual portals on demand. You can also use it to list the virtual portals that exist in your portal.

After you complete a regular portal installation, the portal is ready and enabled for implementing virtual portals. You can create additional virtual portals for your business as and when you need.

When you create a new virtual portal, you enter or select the following properties of the new virtual portal as required:

  • The title for the new virtual portal. This field is limited to 255 characters.
  • A description of the new virtual portal. This field is limited to 255 characters.
  • A human readable URL context that is used for accessing the virtual portal. You can set a URL that can be easily remembered and is therefore more user friendly than the actual full portal URL. The portal maps the friendly URL to the internal URL of the virtual portal. To do this, it uses the portal URL Mapping feature.

    The string that you enter will be used as the last part of the URL of the virtual portal and will be appended to http://www.setgetweb.com/wps/portal/.

    All virtual portal URL contexts must be built from the root context for the portal server and must be unique. They cannot be sub-contexts. For example, this URL is invalid:

        http://www.setgetweb.com/wps/portal/vp1/vp2.

    This is the correct format:

        http://www.setgetweb.com/wps/portal/vp2.

  • The Member Manager realm that contains the user population of the virtual portal. This entry field is only shown if your portal installation supports realms. If you leave the realm field blank, the user population will span the entire user registry. If you use a single common user repository for all virtual portals, for example the WebSphere Application Server LDAP custom user registry, this entry field is not shown.
  • The initial sub-administrator user group for the virtual portal. The portal gives this group Administrator access rights on the new root content node and all its child pages. This group must be within the realm specified for the virtual portal.
  • The Default theme that is applied to the pages of the virtual portal. You select the default theme from a pulldown list. By the default configuration for virtual portals a subadministrator cannot change that default theme, unless you change the roles and access rights give to the subadministrator.

After you enter this information, you create the new virtual portal. With that information the portlet triggers a sequence of processes to establish the new virtual portal. These include:

  • Create a new root content node for the virtual portal.
  • Create the new URL mapping to point to the new root content node.
  • Assigning the selected theme to the new root content node.
  • Granting the specified administrator group the action set for the Administrator role on the new root content node and thereby on the new virtual portal.
  • Calling the XML configuration interface script to create the initial content tree. This includes virtual portal specific instances of the following portal resources: Favorites, Administration, My Portal, Manage Portlets, and Page Customizer with the corresponding concrete portlets. For a complete list refer to Content of a virtual portal.

    To change the content globally and before creating a virtual portal, modify the XML script that specifies the initial content for virtual portals. For details about how to do this refer to Preconfiguring the default content for virtual portals.

  • Assigning default roles and access rights to subadministrators and users on the created resources.

Besides creating a virtual portal, you can also use the Manage Virtual Portals portlet to perform the following tasks:

  • Edit a virtual portal. This allows you to modify the title and description of the virtual portal. You can also set locale-specific titles and descriptions.
  • Re-initialize the virtual portal. This applies the InitVirtualPortal.xml script again and recreates the default content of a virtual portal. If you replaced the default XML script with your own and configured the Manage Virtual Portals portlet accordingly, your custom script is reapplied.
  • Delete a virtual portal.

    Note: This deletes the virtual portal, its initial URL Mapping, and all the corresponding scoped resources. It does not delete the unscoped resources from the initial portal installation or additional URL Mappings that administrators might have created.

 

Preconfiguring the Manage Virtual Portals portlet

When use the Manage Virtual Portals portlet to create a virtual portal, the portlet creates the new virtual portal with default portal content and resources. It also creates default access rights for the virtual portal subadministrators on those resources. You can change both the default portal content and the default access rights for the subadministrators globally and before creating a virtual portal. To do this, you configure the Manage Virtual Portals portlet and the default XML script:

 

Using configuration tasks for administering virtual portals

WebSphere Portal provides the following configuration tasks that you can use perform the following work with virtual portals:

  • Create virtual portals
  • List all virtual portals
  • Modify a virtual portal
  • Delete a virtual portal.

For more detail about these configuration tasks and how to use them refer to Configuration tasks for administering virtual portals.

 

Using the XML configuration interface to work with virtual portals

You can export and import individual virtual portals by using the XML configuration interface. For example, you can use the XML configuration interface to fill a newly created virtual portal with content.

As each virtual portal has its own globally unique portal ID, all resources associated with that virtual portal can be clearly determined. You specify the unique virtual portal URL with your XML request as follows: 

   xmlaccess -user user -password password -url myhost:8082/wps/config/URL_mapping_context_of_the_VP -in XML_file -out result.xml

For the URL Mapping context use the Mapping that you specified when you created the virtual portal. For more information about the XML configuration interface and how you use it refer to the XML configuration interface .

You can only export and import a single individual virtual portal at a time by using the XML configuration interface. You cannot export or import multiple virtual portals at the same time or an entire portal installation with virtual portals. You need to specify a separate XML request for each virtual portal. You can also export content from one virtual portal and import it into a different virtual portal.

The access rights for the XML configuration interface are limited to the master administrator of the portal installation as a whole. Subadministrators for the virtual portals cannot use the XML configuration interface to export or import the virtual portal which they administer.

Note: Apply special care when you configure unscoped resources using the XML configuration interface. Unscoped resources are shared between all virtual portals across the entire portal installation. A change of unscoped resources by the XML configuration interface affects all other virtual portals. For example, this applies to the following tasks and types of XML processing:

  • Updating URL Mappings by using the XML configuration interface: A URL Mapping in one virtual portal can be unintentionally updated by XML import into another virtual portal to point to a resource in that second virtual portal. Therefore, if you export the content of one virtual portal and import it into a different virtual portal, verify you do not to include the URL mapping contexts in the XML script. Otherwise the URL mappings of the source virtual portal are updated to point to resources in the target virtual portal into which you imported the content. You can no longer use such a URL Mapping to access the resource in the source virtual portal.

    This is particularly critical for the URL Mapping that is created for a virtual portal during its creation. Updating this initial URL Mapping of a virtual portal makes that virtual portal unusable.

  • Deploying portlet applications into a virtual portal by using the XML configuration interface: If you deploy a portlet, this makes that portlet available to all virtual portals in the portal installation, unless you restrict this by using Portal Access Control. If that portlet has already been deployed in other virtual portals, errors can occur during the execution of the XML request.

For more information about scoped and unscoped resources refer to Separating and sharing resources between virtual portals

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.