Administer virtual portals

 

+

Search Tips   |   Advanced Search

 

1. Overview
2. User repository for a virtual portal
3. Preconfigure virtual portals
4. Preconfigure the default content
5. Preconfigure subadministrators for virtual portals
6. Create a virtual portal
7. Fill a virtual portal with content
8. Configure subadministrators for virtual portals
9. List all virtual portals
10. Modify a virtual portal
11. Delete a virtual portal
12. Administer the portal content and resources
13. Administer the users for virtual portals
14. Administer content and search with virtual portals
15. Use the Virtual Portal Manager administration portlet
16. Preconfigure the Virtual Portal Manager portlet
17. Use configuration tasks for administering virtual portals
18. Use the XML configuration interface to work with virtual portals

Overview

This topic describes how you can scope your WebSphere Portal to have multiple virtual portals.

Administer...

• Portal content and resources for virtual portals
• Users for virtual portals
• Content and search with virtual portals

Tools...

• Virtual Portal Manager administration portlet
• Configuration tasks
• xmlaccess

 

User repository for a virtual portal

Portal default security is Federated Security

WebSphere Portal also supports the LDAP user registries. To enable...

wp-modify-ldap-security

 

Preconfigure virtual portals

New virtual portals created by the Virtual Portal Manager portlet are set up with content and a set of access rights on the content for the specified subadministrator group.

 

Preconfigure the default content

When you create the virtual portal by using the Virtual Portal Manager portlet, the virtual portal is pre-filled with default content. This default content is determined by the default XML script file for initializing virtual portals. This file can have different names, for example...

• InitVirtualPortal.xml
• InitVirtualContentPortal.xml
• InitAdminVirtualPortal.xml

...depending on your portal installation. It is located in...

• UNIX/Windows

  was_profile_root/installedApps/cell/wps.ear/wps.war/virtualportal

• i5/OS:

  AppServer_root_usr/installedApps/cell/wps.ear/wps.war/virtualportal

To find out which file is used for creating virtual portals in your installation open the Manage Virtual Portals portlet and select the option Edit Shared Settings from the portlet context menu. This shows the XML file name.

To find out which content virtual portals have that you create, review the XML script file under the location given above.

Advanced master administrators can customize the default content for virtual portals as required by modifying or replacing the XML script that specifies the initial content for virtual portals.

When you modify or replace this XML script, plan well ahead and apply special care.

You can add or remove some content in order to enhance or reduce the functionality of a virtual portal to a certain extent. The following portal resources are mandatory content of a virtual portal and must be included in a customized XML initialization script for virtual portals:

Content Root	wps.content.root
Login	wps.Login
Administration	ibm.portal.Administration

Depending on the functionality that you want to make available, more content is required. For example, in order to allow templating, include...

Application Root	wps.application.root
Templates	ibm.portal.Templates

To replace the default XML script by your own custom XML script...

1. Place your custom XML script in...

   • UNIX/Windows:

     was_profile_root/installedApps/cell/wps.ear/wps.war/virtualportal

   • i5/OS:

     AppServer_root_usr/installedApps/cell/wps.ear/wps.war/virtualportal

2. Open the Manage Portlets portlet by clicking...

   Administration | Portlet Management | Portlets | Virtual Portal Manager | Configure Portlet (wrench) icon

3. 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 re-enter the parameter with the name of your XML file.

4. Click OK twice to save your changes.

 

Preconfigure subadministrators for virtual portals

To configure roles and access rights assigned to subadministrators on portlets of a virtual portal globally, before you create a virtual portal...

1. Open the Manage Portlets portlet by clicking...

   Administration | Portlet Management | Portlets | Virtual Portal Manager

   

   ...and click the Configure Portlet (wrench) icon of the Virtual Portal Manager portlet.

   

2. To change the list of portlets to which subadministrators have access, set portletListNeedAccess...

   1. Remove portlets for which you want subadministrators to have no access rights.

   2. Add portlets as required by adding the unique names of the portlets to the list.

   The default list contains all portlets listed under Content of a virtual portal.

3. To grant access rights to subadministrators, set actionSetName

   The default role is Editor.

   Valid values...

   Administrator, Security Administrator, Delegator, Manager, Editor, Privileged User, User

4. Click OK to save your changes.

 

Create a virtual portal

You can create virtual portals using the Virtual Portal Manager portlet.

Specify the following attributes...

Title of the virtual portal.	This title is later displayed in the list of virtual portals in the Virtual Portal Manager portlet. The title is not visible for end users of the virtual portal.
Description for the virtual portal.	Optional.
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. There are some strings which you cannot use as URL mappings for virtual portals, for example vp. These strings are reserved names and correspond with URL codec names. For a list of these reserved strings refer to Planning for virtual portals.
Hostname of the virtual portal.	Optional. Use it to add a hostname of your choice for the virtual portal. The portal uses that hostname for the friendly URL of the virtual portal as follows... http://your_hostname_example:port/wps/portal You cannot use the same virtual portal hostname twice in the same portal installation.
User group of subadministrators who will be able to administer the virtual portal.
Realm that represents the user population for the virtual portal.	This field is only shown if your portal configuration supports realms.
Theme of the virtual portal.

As an alternative you use the a configuration task to create virtual portals.

If you use the configuration task...

create-virtual-portal

...to create a virtual portal, the virtual portal is created without content.

If no virtual portal title is given in the language which is either defined as the user-preferred language or defined in the user's browser, the display fallback will use the unique name if present, or a string version of the ObjectID.

To display the virtual portal title and content root correctly, do either....

• Select the preferred language for the portal user
• Define the display language in the user's browser

 

Filling a virtual portal with content

When you create a virtual portal by using the Virtual Portal Manager portlet, the portlet fills the new virtual portal with default content. This default content is determined by the default XML script file for initializing virtual portals.

If you want different content in your virtual portal, you can configure your own custom script file.

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 xmlaccess to fill the virtual portal with content.

 

Configure subadministrators for virtual portals

When you create a virtual portal the Virtual Portal Manager 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 Virtual Portal Manager portlet creates a set of necessary access rights on the virtual portal for the subadministrator group specified.

This includes Editor role access rights on the administration portlets that are part of a virtual portal. As a result, subadministrators of a virtual portal can perform administrative tasks on the virtual portal with these administration portlets.

To change default access rights for subadministrators, you can do one of the following:

• To change roles and access rights for subadministrators on portlets globally and before you create a virtual portal, configure the Virtual Portal Manager portlet accordingly.

• 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 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 Manage Search portlet requires that you assign the following to virtual portal administrators...

Editor@Virtual Resource PSE_SOURCES

Do not grant 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 subadministrators of the virtual portal. In this case assign the required roles manually or by using the portal xmlaccess.

Granting virtual portal administrators access to Web content librariesVirtual portal administrators do not automatically have access to work with Web content libraries when using the administration portlet. To enable a virtual portal administrator to work with Web content libraries you will need to assign them access to either the JCR content root node or individual Web content libraries:

• You 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.

  • 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 have created.

• You can also assign virtual portal administrators access to libraries they have not created by editing the access settings of individual libraries.

 

List all virtual portals

You can list all virtual portals by using either the Virtual Portal Manager portlet or using a configuration task.

 

Modify a virtual portal

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

title of the virtual portal.
description of the virtual portal.
realm of the virtual portal.	Apply special care when changing the realm of a virtual portal. Changing the realm of a virtual portal might change the users and groups who have access to the virtual portal and to resources of that virtual portal. This includes the possibility that subadministrator of the virtual portal can lose the rights to administer the portal. If this happens, change the realm back to the original realm by using the initial portal installation as an administrative interface.
theme of the virtual portal.

As an alternative, you can perform the same modifications by using a configuration task.

 

Delete a virtual portal

You can delete a virtual portal by using the Virtual Portal Manager portlet.

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

You cannot delete the initial portal installation.

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.

If you delete a virtual portal and you want to create a new virtual portal immediately after the deletion using the same URL context, you do not have to wait for the scheduled cleanup service. Run the cleanup task for deleting resources by running the XML script Task.xml using xmlaccess. Then you can create the new virtual portal.

 

Administering the portal content and resources

When you create a virtual portal by using the Virtual Portal Manager portlet, the portlet also creates default portal content and resources for the virtual portal. This default content is determined by the default XML script file for initializing virtual portals. The default content of a virtual portal is listed under Multiple virtual portlets.

In general, you can administer portal resources for a virtual portal just like you do for a normal 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. 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.

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 default XML script that specifies the initial 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 xmlaccess to import content into the virtual portal. This can only be done from the initial portal installation.

When you create a virtual portal, the portlets associated with IBM Lotus WCM are not included in the virtual portal, even if you have deployed these portlets as part of your original portal installation. To use any of these portlets in a virtual portal, manually create a page and add the portlets:

Authoring portlet	Select Web Content Authoring when adding the portlet.
Local or Remote Rendering portlet	Select Web Content Viewer when adding the portlet.

 

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 Virtual 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:

• For scoped resources:

  Access rights that you configured for users on scoped resources of the initial portal installation are not passed on to similar resources of a virtual portal. This statement applies only to resources scoped for each virtual portal, such as pages or portlet instances, but not for shared resources. For example, if you restricted access rights to some pages or portlet instances for users on the initial portal installation, these restrictions do not apply for the users of the virtual portal.

• The All Authenticated Portal Users group and the All Portal User Groups are 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.

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 subadministrators of the virtual portal perform this task.

 

Administering content and search with virtual portals

Personalization is not aware of virtual portals. A document library that is available in the initial portal installation is also available in each virtual portal, if 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.

 

Use the Virtual Portal Manager administration portlet

The Virtual Portal Manager portlet allows you to...

• Create additional virtual portals on demand
• List the virtual portals that exist in the 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:

title for the new virtual portal. This field is limited to 255 characters.
description of the new virtual portal. This field is limited to 255 characters.
human readable URL context that is used for accessing the virtual portal.	You can set a friendly URL using portal's 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.example.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.example.com/wps/portal/vp1/vp2 This is the correct format: http://www.example.com/wps/portal/vp2
hostname for the virtual portal. Optional.	Use it to add a hostname of your choice for the virtual portal. The portal uses that hostname for the friendly URL of the virtual portal as follows... http://your_hostname_example:port/wps/portal You cannot use the same virtual portal hostname twice in the same portal installation.
Virtual 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 be the same as for the default realm. If you use a single common user repository for all virtual portals, for example the WAS LDAP custom user registry, this entry field is not shown.
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.
Default theme that is applied to the pages of the virtual portal.	You select the default theme from a pull-down list. By the default configuration for virtual portals a subadministrator cannot change that default theme, unless you change 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....

• Create a new root content node for the virtual portal.

• Create the new URL mapping to point to the new root content node.

• Assign the selected theme to the new root content node.

• Grant the specified administrator group the action set for the Administrator role on the new root content node and thereby on the new virtual portal.

• Call xmlaccess script to create the initial content tree.

  This includes virtual portal specific instances of the following portal resources:

  • Favorites
  • Administration
  • Home
  • Manage Portlets
  • Page Customizer

  ...with the corresponding concrete portlets. To change the content globally and before creating a virtual portal, modify the XML script that specifies the initial content for virtual portals.

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

Besides creating a virtual portal, you use the Virtual Portal Manager portlet to perform the following tasks:

• Edit a virtual portal. This allows one 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 Virtual Portal Manager portlet accordingly, your custom script is reapplied. Resources that you removed from the default content are recreated.

  Resources that you added to the default content remain in the virtual portal.

• Delete a virtual portal. This deletes the virtual portal, its initial URL mapping, and all the corresponding scoped resources.

  This does not delete the unscoped resources from the initial portal installation or additional URL mappings that administrators might have created.

 

Preconfigure the Virtual Portal Manager portlet

When you use the Virtual Portal Manager 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 subadministrators globally and before creating a virtual portal. To do this, you configure the Virtual Portal Manager portlet and the default XML script:

 

Use configuration tasks for administering virtual portals

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

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

 

Use the XML configuration interface to work with virtual portals

You can export and import individual virtual portals by using xmlaccess. For example, use xmlaccess 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:10040/URL_Context_of_the_Virtual_Portal -in XML_file -out result.xml

For the variable URL_Context_of_the_Virtual_Portal use the URL context specified when you created the virtual portal.

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. 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 xmlaccess 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.

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:

• Update URL mappings by using xmlaccess:

  A URL mapping of a URL context 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, make sure that you do not to include the URL mappings of virtual portal URL contexts in the XML script. Otherwise, you might make the virtual portal unusable in the following two circumstances:

  • If the source virtual portal and the target virtual portal are on the same Portal server, 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 context to access the resource in the source virtual portal.

  • If the source virtual portal and the target virtual portal are not on the same Portal server, but there is another virtual portal on the target Portal server which has the same URL context as that of the source virtual portal.

    The URL mappings of this virtual portal will be updated to point to resources in the target virtual portal into which you imported the content. And you can no longer use such a URL context to access the resource in this virtual portal.

  This is particularly critical for the URL mapping of a URL context that is created for a virtual portal during its creation. Updating this initial URL mapping of a virtual portal URL context 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.

 

Parent topic

Multiple virtual portals